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: Peter Maydell
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:01:26 +0000

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.

>> 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 this point in the conversation I'm pretty confused about exactly
what we're trying to do :-))

-- PMM



reply via email to

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