qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices
Date: Thu, 10 Jan 2013 13:45:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Il 10/01/2013 13:31, Peter Maydell ha scritto:
> On 10 January 2013 12:12, Paolo Bonzini <address@hidden> wrote:
>> Il 10/01/2013 12:59, Peter Maydell ha scritto:
>>>>>>>>>>> It's possible.  I'll move the SCSI bus away from qdev reset.
>>>>>>>>>>> Anthony/Michael, can you help doing the same with PCIDevice?  And
>>>>>>>>>>> perhaps Peter and Andreas with sysbus?
>>>>>>> What does it even mean to reset a sysbus? Do we do it anywhere?
>>>>>>> (it looks like vl.c does, just as a shortcut so memory mapped devices
>>>>>>> get their reset hooks called?)
>>> So how should it work instead? I kind of feel like all qdev devices should
>>> get their reset hook called on machine reset, regardless of bus [since it's
>>> modelling power cycling the whole system], but would that break
>>> something?
>>
>> It's just an implementation detail.  Right now we have a common
>> callback.  The idea is to give each bus its own callback.  In the case
>> of sysbus it would just call a method; for PCI it would reset some
>> configuration and then call a method; for SCSI there is no need to call
>> a method at all; and so on.
> 
> But machine reset shouldn't call bus specific PCI or SCSI reset
> methods -- we've just effectively yanked the power to the VM
> so everything should just reset as if it was freshly constructed.

Yes, but we do not have a way to do that, so QEMU resorts to a warm reset.

> A bus-specific reset method would be for buses where the bus
> itself has some sort of guest-triggerable reset (by prodding the
> chipset, for instance).

Yes.

>> In addition, navigating the qdev tree should be explicit in the methods.
>>  It will not happen anymore via the "magic" qdev_reset_all.
> 
> *Something* has to say "call reset for every qdev object in the
> system", surely?

It will call it on sysbus, which will call it on every sysbus child.
Devices that have a child bus will propagate it further down.

Paolo



reply via email to

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