From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGr7E-0000dw-9T for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:07:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGr78-0000dB-Ou for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:07:31 -0400 Received: from [199.232.76.173] (port=46474 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGr78-0000d8-DU for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:07:26 -0400 Received: from mail-ew0-f220.google.com ([209.85.219.220]:34687) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGr77-0001XD-1l for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:07:25 -0400 Received: by ewy20 with SMTP id 20so206060ewy.34 for ; Wed, 17 Jun 2009 02:07:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090616124702.GS19508@redhat.com> References: <20090616124702.GS19508@redhat.com> Date: Wed, 17 Jun 2009 11:07:24 +0200 Message-ID: <5b31733c0906170207u1c553f6by67eb814644f55a10@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH] Register usb-uhci reset function. From: Filip Navara Content-Type: multipart/alternative; boundary=0016367d6a3c9afc01046c879ef3 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org --0016367d6a3c9afc01046c879ef3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Jun 16, 2009 at 2:47 PM, Gleb Natapov wrote: > Update irq line on reset. Reseting irq line is required because > racing irq from pci device will call piix3_set_irq(). piix3_set_irq() > will remember current level in pci_irq_levels[]. The PIC line will be > triggered if one of pci_irq_levels[] is set (depends on piix3 config). > If for instance pci_irq_levels[0] and pci_irq_levels[1] are mapped to > the same PIC irq and during reset pci_irq_levels[1] == 1, but device > that drives pci_irq_levels[0] is initialized first the device driver > will not be able to lower irq line. > I have been trying to stay away from the discussion for a long while, but I can't keep it anymore. The patch is wrong. Since qemu_irq doesn't hold any state, the information on reset has to be cleared on the places where the state is maintained. Under no circumstances should any *_set_irq() function should be called from reset handlers! Especially since the order of reset handlers is not guaranteed. The reseting of the interrupt state in practice means that interrupt status registers of individual devices should be cleared, the PCI bus interrupt levels should be cleared - *in the PCI reset handler* and so on. Eventually you will end up with reset handlers that clear the state at every level, so there won't be any "hanging interrupts" after reset. Best regards, Filip Navara --0016367d6a3c9afc01046c879ef3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 16, 2009 at 2:47 PM, Gleb Natapov <gleb@redhat.com&= gt; wrote:
Update irq line on reset. Reseting irq line is required because
racing irq from pci device will call piix3_set_irq(). piix3_set_irq()
will remember current level in pci_irq_levels[]. The PIC line will be
triggered if one of pci_irq_levels[] is set (depends on piix3 config).
If for instance pci_irq_levels[0] and pci_irq_levels[1] are mapped to
the same PIC irq and during reset pci_irq_levels[1] =3D=3D 1, but device that drives pci_irq_levels[0] is initialized first the device driver
will not be able to lower irq line.

I have b= een trying to stay away from the discussion for a long while, but I can'= ;t keep it anymore. The patch is wrong. Since qemu_irq doesn't hold any= state, the information on reset has to be cleared on the places where the = state is maintained. Under no circumstances should any *_set_irq() function= should be called from reset handlers! Especially since the order of reset = handlers is not guaranteed. The reseting of the interrupt state in practice= means that interrupt status registers of individual devices should be clea= red, the PCI bus interrupt levels should be cleared - *in the PCI reset han= dler* and so on. Eventually you will end up with reset handlers that clear = the state at every level, so there won't be any "hanging interrupt= s" after reset.

Best regards,
Filip Navara
--0016367d6a3c9afc01046c879ef3--