From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGe6X-0003VB-Pz for qemu-devel@nongnu.org; Tue, 16 Jun 2009 15:13:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGe6T-0003KO-Ek for qemu-devel@nongnu.org; Tue, 16 Jun 2009 15:13:57 -0400 Received: from [199.232.76.173] (port=33419 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGe6S-0003Js-A1 for qemu-devel@nongnu.org; Tue, 16 Jun 2009 15:13:52 -0400 Received: from mx2.redhat.com ([66.187.237.31]:54686) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGe6R-00081O-RW for qemu-devel@nongnu.org; Tue, 16 Jun 2009 15:13:52 -0400 Date: Tue, 16 Jun 2009 22:11:48 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH] Register usb-uhci reset function. Message-ID: <20090616191148.GI782@redhat.com> References: <20090616124702.GS19508@redhat.com> <200906161814.58491.paul@codesourcery.com> <20090616173723.GF782@redhat.com> <200906161941.06191.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906161941.06191.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Tue, Jun 16, 2009 at 07:41:05PM +0100, Paul Brook wrote: > >> If allow devices to be reset independently then they should probably set > >> theit IRQ output on reset. > > > >It is not "if" it is "when". We have to allow device to be reset > > independently for hot-unplug. > > I'm not entirely convinced about reset-on-hotunplug. What about a device that > pulls its IRQ line high on reset? > There are several different resets for device. SW reset (triggered by driver issuing a command), HW reset (triggered by external reset signal). If they are different device should implement them differently. HW reset should be called on device unplug. And if spec says that device pulls its IRQ line high on HW reset then device emulation should do that too. > > > The only relevant circumstances are if the devices raises an IRQ, and is > > > then reset by software while the system is running. It's got nothing to > > > do with piix3, PCI bus interrupt sharing or system reset. If you are > > > seeing problems after a system reset then your bug lies elsewhere. > > > > So you apparently never heard about hardware reset? You never saw buggy > > guests that does not reset HW before reboot? > > Clearing device state on full system reset makes sense because the whole point > is that we're returning the system to its power-on state. Power-up state is not always the same as the state after triggering reset on real HW. System reset in QEMU currently emulates neither of them properly. And on real HW there are different power planes and they can be powered down independently. QEMU can't emulates this neither. > Lowering the IRQ when a single device is reset also makes sense. > It is much more simple then that. If spec says that IRQ line should be lowered on reset we should code it this way. (Spec may say this indirectly. It may say that IRQ level is an AND of N registers and on reset those registers are cleared). > However having the device explicit set its IRQ line during a full system reset > is a different matter. This is probably harmless most of the time, and may > paper over other bugs (e.g. the PCI bus not being reset properly). However I > do not believe it is the correct justification for these changes. > The IRQ state inside piix3 code is QEMU implementation detail. There is now such thing on real HW. The real bug in case of usb-uhci is that it is not reset on system reset. Are you arguing with that too, or just with IRQ level bits? -- Gleb.