Re: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

2012/2/20 Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu: react to 
> XenbusStateClosing"):
>> On Mon, 16 Jan 2012, Roger Pau Monne wrote:
>> > Qemu was not reacting when setting xenstore state of a device to
>> > XenbusStateClosing (5). This patch makes qemu react to this state and
>> > close the appropiate device.
>> >
>> > Signed-off-by: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
>>
>> Please send a version of this patch against upstream qemu and CC
>> qemu-devel as well.
>
> We are trying to avoid adding new code and new features to
> qemu-xen-unstable. ÂCan you explain what the practical impact of this
> patch is ? ÂWhen is it needed and what doesn't work without it ?

This is not really needed now, qdisk backends are destroyed the hard
way (remove xenstore backend and signal qemu-dm). The normal process
for destroying a backend however should be to wait for it to reach
state 6, and qemu-dm backend implementation doesn't react to setting
backend state to 5, as most backends do. This patch was trying to fix
this by making qemu-dm aware of a close request.

> Has the thing which doesn't work without it ever worked before destroying

As said before, device shutdown/destruction in libxl is forced right
now, the frontend/backend is destroyed and the device model signaled
(if there's a device model). This will change with the hotplug/device
domain series, since we can no longer destroy the backend xenstore
entries before unplugging the device because we have to call hotplug
scripts when the device has reached a closed state (6).

We could make an exception with qemu devices, but I would prefer to
avoid that and use the same unplug path for all device types.

> Thanks,
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xensource.com/xen-devel