From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGdas-0002aq-3x for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:41:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGdan-0002aF-Md for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:41:13 -0400 Received: from [199.232.76.173] (port=60545 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGdan-0002aC-FT for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:41:09 -0400 Received: from mx20.gnu.org ([199.232.41.8]:50324) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MGdan-0002Zn-66 for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:41:09 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGdam-0007XL-0C for qemu-devel@nongnu.org; Tue, 16 Jun 2009 14:41:08 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Register usb-uhci reset function. Date: Tue, 16 Jun 2009 19:41:05 +0100 References: <20090616124702.GS19508@redhat.com> <200906161814.58491.paul@codesourcery.com> <20090616173723.GF782@redhat.com> In-Reply-To: <20090616173723.GF782@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906161941.06191.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Gleb Natapov >> 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? > > 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. Lowering the IRQ when a single device is reset also makes sense. 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. Paul