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 14:32:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Il 10/01/2013 14:01, Peter Maydell ha scritto:
> On 10 January 2013 12:45, Paolo Bonzini <address@hidden> wrote:
>> Il 10/01/2013 13:31, Peter Maydell ha scritto:
>>> On 10 January 2013 12:12, Paolo Bonzini <address@hidden> wrote:
>>>> 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.
> 
> qdev reset is cold reset, not warm reset.

Whatever. :)  It resorts to a reset (as if it was freshly constructed)
instead of _really_ doing a fresh construction.

>>> 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.
> 
> This doesn't work when we get rid of the idea that every qdev
> device is attached to a tree of buses.

At least for now, devices that should be bus-free are sysbus devices,
aren't they?

Paolo




reply via email to

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