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@entel.upc.edu>
---
hw/xen_backend.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 64dc93a..4e4dd77 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -285,11 +285,23 @@ static struct XenDevice *xen_be_del_xendev(int dom, int
dev)
*/
static void xen_be_backend_changed(struct XenDevice *xendev, const char *node)
{
+ int be_state;
+
if (node == NULL || strcmp(node, "online") == 0) {
if (xenstore_read_be_int(xendev, "online", &xendev->online)
== -1)
xendev->online = 0;
}
+ if (node != NULL && strcmp(node, "state") == 0) {
+ if (xenstore_read_be_int(xendev, "state", &be_state) ==
-1) {
+ xendev->be_state = XenbusStateUnknown;
+ } else if (xendev->be_state == be_state) {
+ return;
+ } else {
+ xendev->be_state = be_state;
+ }
+ }
+
if (node) {
xen_be_printf(xendev, 2, "backend update: %s\n", node);
if (xendev->ops->backend_changed)
@@ -461,8 +473,7 @@ static void xen_be_try_connected(struct XenDevice *xendev)
*/
static void xen_be_disconnect(struct XenDevice *xendev, enum xenbus_state
state)
{
- if (xendev->be_state != XenbusStateClosing &&
- xendev->be_state != XenbusStateClosed &&
+ if (xendev->be_state != XenbusStateClosed &&
xendev->ops->disconnect)
xendev->ops->disconnect(xendev);
if (xendev->be_state != state)
@@ -513,6 +524,9 @@ void xen_be_check_state(struct XenDevice *xendev)
xen_be_try_connected(xendev);
rc = -1;
break;
+ case XenbusStateClosing:
+ xen_be_disconnect(xendev, XenbusStateClosed);
+ break;
case XenbusStateClosed:
rc = xen_be_try_reset(xendev);
break;
--
1.7.2.5
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@entel.upc.edu>Please send a version of this patch against upstream qemu and CC qemu-devel as well.> --- > hw/xen_backend.c | 18 ++++++++++++++++-- > 1 files changed, 16 insertions(+), 2 deletions(-) > > diff --git a/hw/xen_backend.c b/hw/xen_backend.c > index 64dc93a..4e4dd77 100644 > --- a/hw/xen_backend.c > +++ b/hw/xen_backend.c > @@ -285,11 +285,23 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev) > */ > static void xen_be_backend_changed(struct XenDevice *xendev, const char *node) > { > + int be_state; > + > if (node == NULL || strcmp(node, "online") == 0) { > if (xenstore_read_be_int(xendev, "online", &xendev->online) == -1) > xendev->online = 0; > } > > + if (node != NULL && strcmp(node, "state") == 0) { > + if (xenstore_read_be_int(xendev, "state", &be_state) == -1) { > + xendev->be_state = XenbusStateUnknown; > + } else if (xendev->be_state == be_state) { > + return; > + } else { > + xendev->be_state = be_state; > + } > + } > + > if (node) { > xen_be_printf(xendev, 2, "backend update: %s\n", node); > if (xendev->ops->backend_changed) > @@ -461,8 +473,7 @@ static void xen_be_try_connected(struct XenDevice *xendev) > */ > static void xen_be_disconnect(struct XenDevice *xendev, enum xenbus_state state) > { > - if (xendev->be_state != XenbusStateClosing && > - xendev->be_state != XenbusStateClosed && > + if (xendev->be_state != XenbusStateClosed && > xendev->ops->disconnect) > xendev->ops->disconnect(xendev); > if (xendev->be_state != state) > @@ -513,6 +524,9 @@ void xen_be_check_state(struct XenDevice *xendev) > xen_be_try_connected(xendev); > rc = -1; > break; > + case XenbusStateClosing: > + xen_be_disconnect(xendev, XenbusStateClosed); > + break; > case XenbusStateClosed: > rc = xen_be_try_reset(xendev); > break; > -- > 1.7.2.5 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >
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@entel.upc.edu>
>
> 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 ?
Has the thing which doesn''t work without it ever worked before
destroying
Thanks,
Ian.
2012/2/20 Ian Jackson <Ian.Jackson@eu.citrix.com>:> 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@entel.upc.edu> >> >> 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 destroyingAs 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@lists.xen.org http://lists.xensource.com/xen-devel
On Tue, 21 Feb 2012, Roger Pau Monné wrote:> 2012/2/20 Ian Jackson <Ian.Jackson@eu.citrix.com>: > > 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@entel.upc.edu> > >> > >> 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 --8323329-324981304-1329819390=:23091 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xensource.com/xen-devel --8323329-324981304-1329819390=:23091--