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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 21 Feb 2012, Roger Pau Monnà wrote:
> 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.

I would consider it a bug that should be fixed


> > 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.
 
I agree

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