From: Gleb Natapov <gleb@redhat.com>
To: Filip Navara <filip.navara@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Register usb-uhci reset function.
Date: Wed, 17 Jun 2009 12:43:18 +0300 [thread overview]
Message-ID: <20090617094318.GX19508@redhat.com> (raw)
In-Reply-To: <5b31733c0906170207u1c553f6by67eb814644f55a10@mail.gmail.com>
On Wed, Jun 17, 2009 at 11:07:24AM +0200, Filip Navara wrote:
> On Tue, Jun 16, 2009 at 2:47 PM, Gleb Natapov <gleb@redhat.com> 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
The fact that qemu_irq() doesn't hold any state has nothing to do with
what should be done on device reset. Nothing at all, nada, zilch. You
can repeat this many times more and it will not became more relevant.
What is important is that only device knows what irq level should be at
any given moment, and qemu_irq() is the way to communicate this to the
system. And if it want to drive irq high on reset it should be able to
do that.
> 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.
>
This will not work for reseting individual device (needed by hot-unplug)
since pci chipset reset is not called. Instead of fixing problem at
the level that needs fixing (device reset level) you propose to hack
solution into piix3 code. "Yaeh, gdb shows we have a wrong value in some
random array, why is it there? Who cares, lest zero this thing and forget
about it." And BTW _I_ send patch to do just that a week or so ago, and
I think it should be applied along with reseting irq line in device
reset handler just to prevent buggy devices from hanging a guest.
--
Gleb.
next prev parent reply other threads:[~2009-06-17 9:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 12:47 [Qemu-devel] [PATCH] Register usb-uhci reset function Gleb Natapov
2009-06-16 17:14 ` Paul Brook
2009-06-16 17:37 ` Gleb Natapov
2009-06-16 18:41 ` Paul Brook
2009-06-16 19:11 ` Gleb Natapov
2009-06-16 19:38 ` Paul Brook
2009-06-16 22:57 ` Zachary Amsden
2009-06-17 8:12 ` Gleb Natapov
2009-06-16 18:02 ` Blue Swirl
2009-06-16 19:19 ` Anthony Liguori
2009-06-16 19:26 ` Gleb Natapov
2009-06-17 9:07 ` Filip Navara
2009-06-17 9:43 ` Gleb Natapov [this message]
2009-06-17 10:17 ` Filip Navara
2009-06-17 11:06 ` Gleb Natapov
2009-06-17 11:25 ` Dor Laor
2009-06-17 11:39 ` Gleb Natapov
2009-06-17 11:50 ` Filip Navara
2009-06-17 11:36 ` Filip Navara
2009-06-17 12:12 ` Gleb Natapov
2009-06-17 13:03 ` Filip Navara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090617094318.GX19508@redhat.com \
--to=gleb@redhat.com \
--cc=filip.navara@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).