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: Gleb Natapov
Subject: Re: [Qemu-devel] Register uhci_reset() callback.
Date: Tue, 16 Jun 2009 20:47:25 +0300

On Tue, Jun 16, 2009 at 05:54:54PM +0100, Paul Brook wrote:
> On Tuesday 16 June 2009, Gleb Natapov 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
> 
> You're both wrong.
> 
As always.

> 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. The reset mechanism of qemu is not sophisticated to do that yet.
This should be a part of a device model. So I take this statement of
yours as if you agree that each device should reset its irq line. Good.

> 
> IRQ muxes (e.g. PCI busses) should handle reseting and save/restore of their 
> own internal state.
Here are patches. You are welcome to commit them:
http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00342.html
http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00344.html


> Devices should not cause IRQ state changes on restore. Commit 3dcd219f is 
> incorrect.
> 
Don't agree or disagree on this. Haven't thought about it much.

--
                        Gleb.




reply via email to

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