From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JprPQ-0004MR-HN for qemu-devel@nongnu.org; Sat, 26 Apr 2008 16:54:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JprPO-0004JV-NW for qemu-devel@nongnu.org; Sat, 26 Apr 2008 16:54:11 -0400 Received: from [199.232.76.173] (port=48950 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JprPO-0004JK-KJ for qemu-devel@nongnu.org; Sat, 26 Apr 2008 16:54:10 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JprPO-0002fC-6Y for qemu-devel@nongnu.org; Sat, 26 Apr 2008 16:54:10 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [4261] Errors while registering ioports are not fatal (Glauber Costa). Date: Sat, 26 Apr 2008 21:54:06 +0100 References: <200804262108.50036.paul@codesourcery.com> <481392DA.2090809@codemonkey.ws> In-Reply-To: <481392DA.2090809@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804262154.06555.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > > I fail to see how hotplugging or proxing has anything to do with it. IO > > port registration is not something that can reasonably fail. > > > > If the real problem is that we can't cope with multiple devices > > registering the same IO port than you need to fix that. Blindly punting > > to the caller to > > There is no fix for that. You can't have two devices that use the same > IO port. You probably can't meaningfully access the IO port. However I think the registration itself should be allowed. The device shouldn't have to handle this. Just like real hardware doesn't. If you configure two devices with the same IO port I'd expect writes to go to one or both of them, or cause a CPU fault. Just like when you have overlapping memory ranges. The device doesn't suddenly disappear in a puff of smoke because the OS assigned overlapping IO ranges. > > cope is IMHO not an acceptable solution, especially when none of the > > callers check the return value. > > IO port range conflicts can still happen even with PCI devices. Two PCI > IDE controllers would conflict with each other for instance. It's much > more likely with ISA of course but it's still possible. register_ioport > really should have a return code and callers should actively be checking > it. This is why bouncing the error to the device is the wrong thing to do. Once the OS resolves the conflict I'd expect the remaining device to just work. Paul