qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Register uhci_reset() callback.


From: Blue Swirl
Subject: Re: [Qemu-devel] Register uhci_reset() callback.
Date: Tue, 16 Jun 2009 20:19:00 +0300

On 6/16/09, Gleb Natapov <address@hidden> wrote:
> On Tue, Jun 16, 2009 at 07:54:25PM +0300, Blue Swirl wrote:
>  > On 6/16/09, Gleb Natapov <address@hidden> wrote:
>  > > On Tue, Jun 16, 2009 at 06:14:51PM +0300, Blue Swirl wrote:
>  > >  > > Because interrupt line is stuck a guest can't get to the point 
> where it
>  > >  > >  loads a driver to the second device. For outside observer the guest
>  > >  > >  just hangs.
>  > >  >
>  > >  > I see. The problem is in piix_pci interrupt handling, pci_irq_levels[]
>  > >  > should be set to zero on reset.
>  > >
>  > > The patch that does that was rejected earlier :)
>  > >  http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00342.html
>  > >  http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00344.html
>  >
>  > I think patch 2/3 is bogus, but 3/3 should be the correct way. Nobody
>  > commented on that.
>  >
>
> What is bogus about 2/3? But the comment were not about specific patch,
>  more about the general approach. And conclusion was that each device should
>  lower its line. This is how real HW works BTW. IMHO both things should

That was the conclusion then, but it was incorrect. Real HW works like
that, but qemu_irq only handles transition edges. It does not have
state.

>  be done, pci bus should reset its internal state and each device should
>  lower its own line (bus implementation may be changed in the future to
>  more be like real HW).

Bus should reset its own internal state but devices need not do
anything about the qemu_irq. In 2/3 bus would reset also devices,
which is even more wrong.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]