From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jprer-0006uD-6P for qemu-devel@nongnu.org; Sat, 26 Apr 2008 17:10:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jpreo-0006t4-Nr for qemu-devel@nongnu.org; Sat, 26 Apr 2008 17:10:07 -0400 Received: from [199.232.76.173] (port=54453 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jpreo-0006t1-Ii for qemu-devel@nongnu.org; Sat, 26 Apr 2008 17:10:06 -0400 Received: from hs-out-0708.google.com ([64.233.178.243]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jpreo-00055L-3z for qemu-devel@nongnu.org; Sat, 26 Apr 2008 17:10:06 -0400 Received: by hs-out-0708.google.com with SMTP id k27so2870609hsc.2 for ; Sat, 26 Apr 2008 14:10:03 -0700 (PDT) Message-ID: <48139A27.2030601@codemonkey.ws> Date: Sat, 26 Apr 2008 16:09:59 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [4261] Errors while registering ioports are not fatal (Glauber Costa). References: <200804262108.50036.paul@codesourcery.com> <481392DA.2090809@codemonkey.ws> <200804262154.06555.paul@codesourcery.com> In-Reply-To: <200804262154.06555.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook wrote: >>> 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. > We can be better than real hardware here. In the ISA days, having to manually configure a cards IRQ lines to avoid conflicts was a huge pain for users. This is not behavior we should strive to emulate :-) > 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. > The issue isn't the guest OS assigning overlapping IO regions. The issues is that some devices (like IDE), register ioports directly independently of PCI regions. >>> 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. > I don't know how hardware normally handles this. If this is how normal hardware works, then we should emulate that. It's also true though that exit()'ing in register_ioport is the wrong thing to do though. Regards, Anthony Liguori > Paul >