From d297e533a5f653336dbc1c5a24ea196391dff9f5 Mon Sep 17 00:00:00 2001 From: Anthony PERARD Date: Thu, 4 Jul 2019 16:36:05 +0100 Subject: [PATCH 1/4] xen: Fix ring.h header The xen_[rw]?mb() macros defined in ring.h can't be used and the fact that there are gated behind __XEN_INTERFACE_VERSION__ means that it needs to be defined somewhere. QEMU doesn't implement interfaces with the Xen hypervisor so defining __XEN_INTERFACE_VERSION__ is pointless. This leads to: include/hw/xen/io/ring.h:47:5: error: "__XEN_INTERFACE_VERSION__" is not defined, evaluates to 0 [-Werror=undef] Cleanup ring.h. The xen_*mb() macros are already defined in xenctrl.h which is included in xen_common.h. Reported-by: Markus Armbruster Signed-off-by: Anthony PERARD Reviewed-by: Markus Armbruster Message-Id: <20190704153605.4140-1-anthony.perard@citrix.com> [aperard: Adding the comment proposed upstream] Signed-off-by: Anthony PERARD --- include/hw/xen/interface/io/ring.h | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/include/hw/xen/interface/io/ring.h b/include/hw/xen/interface/io/ring.h index 1adacf09f9..5d048b335c 100644 --- a/include/hw/xen/interface/io/ring.h +++ b/include/hw/xen/interface/io/ring.h @@ -33,6 +33,13 @@ * - standard integers types (uint8_t, uint16_t, etc) * They are provided by stdint.h of the standard headers. * + * Before using the different macros, you need to provide the following + * macros: + * - xen_mb() a memory barrier + * - xen_rmb() a read memory barrier + * - xen_wmb() a write memory barrier + * Example of those can be found in xenctrl.h. + * * In addition, if you intend to use the FLEX macros, you also need to * provide the following, before invoking the FLEX macros: * - size_t @@ -42,12 +49,6 @@ * and grant_table.h from the Xen public headers. */ -#if __XEN_INTERFACE_VERSION__ < 0x00030208 -#define xen_mb() mb() -#define xen_rmb() rmb() -#define xen_wmb() wmb() -#endif - typedef unsigned int RING_IDX; /* Round a 32-bit unsigned constant down to the nearest power of two. */ From ba7fdd64b6714af7e42dfbe5969caf62c0823f75 Mon Sep 17 00:00:00 2001 From: Igor Druzhinin Date: Mon, 29 Jul 2019 20:29:23 +0100 Subject: [PATCH 2/4] xen: cleanup IOREQ server on exit Device model is supposed to destroy IOREQ server for itself. Signed-off-by: Igor Druzhinin Acked-by: Paul Durrant Message-Id: <1564428563-1006-1-git-send-email-igor.druzhinin@citrix.com> Signed-off-by: Anthony PERARD --- hw/i386/xen/xen-hvm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index 5d3e4750e6..6b5e5bb7f5 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -1247,6 +1247,8 @@ static void xen_exit_notifier(Notifier *n, void *data) { XenIOState *state = container_of(n, XenIOState, exit); + xen_destroy_ioreq_server(xen_domid, state->ioservid); + xenevtchn_close(state->xce_handle); xs_daemon_close(state->xenstore); } From cb3231460747552d70af9d546dc53d8195bcb796 Mon Sep 17 00:00:00 2001 From: Anthony PERARD Date: Fri, 23 Aug 2019 11:15:33 +0100 Subject: [PATCH 3/4] xen-bus: Fix backend state transition on device reset When a frontend wants to reset its state and the backend one, it starts with setting "Closing", then waits for the backend (QEMU) to do the same. But when QEMU is setting "Closing" to its state, it triggers an event (xenstore watch) that re-execute xen_device_backend_changed() and set the backend state to "Closed". QEMU should wait for the frontend to set "Closed" before doing the same. Before setting "Closed" to the backend_state, we are also going to check if there is a frontend. If that the case, when the backend state is set to "Closing" the frontend should react and sets its state to "Closing" then "Closed". The backend should wait for that to happen. Fixes: b6af8926fb858c4f1426e5acb2cfc1f0580ec98a Signed-off-by: Anthony PERARD Reviewed-by: Paul Durrant Message-Id: <20190823101534.465-2-anthony.perard@citrix.com> --- hw/xen/xen-bus.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c index e40500242d..62c127b926 100644 --- a/hw/xen/xen-bus.c +++ b/hw/xen/xen-bus.c @@ -516,6 +516,23 @@ static void xen_device_backend_set_online(XenDevice *xendev, bool online) xen_device_backend_printf(xendev, "online", "%u", online); } +/* + * Tell from the state whether the frontend is likely alive, + * i.e. it will react to a change of state of the backend. + */ +static bool xen_device_state_is_active(enum xenbus_state state) +{ + switch (state) { + case XenbusStateInitWait: + case XenbusStateInitialised: + case XenbusStateConnected: + case XenbusStateClosing: + return true; + default: + return false; + } +} + static void xen_device_backend_changed(void *opaque) { XenDevice *xendev = opaque; @@ -539,11 +556,11 @@ static void xen_device_backend_changed(void *opaque) /* * If the toolstack (or unplug request callback) has set the backend - * state to Closing, but there is no active frontend (i.e. the - * state is not Connected) then set the backend state to Closed. + * state to Closing, but there is no active frontend then set the + * backend state to Closed. */ if (xendev->backend_state == XenbusStateClosing && - xendev->frontend_state != XenbusStateConnected) { + !xen_device_state_is_active(state)) { xen_device_backend_set_state(xendev, XenbusStateClosed); } From 705be570941b38cd1cbebc68f7f671ce7532ecb0 Mon Sep 17 00:00:00 2001 From: Anthony PERARD Date: Fri, 23 Aug 2019 11:15:34 +0100 Subject: [PATCH 4/4] xen-bus: Avoid rewriting identical values to xenstore When QEMU receives a xenstore watch event suggesting that the "state" of the frontend changed, it records this in its own state but it also re-write the value back into xenstore even so there were no change. This triggers an unnecessary xenstore watch event which QEMU will process again (and maybe the frontend as well). Also QEMU could potentially write an already old value. Signed-off-by: Anthony PERARD Reviewed-by: Paul Durrant Message-Id: <20190823101534.465-3-anthony.perard@citrix.com> --- hw/xen/xen-bus.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c index 62c127b926..a04478ad4f 100644 --- a/hw/xen/xen-bus.c +++ b/hw/xen/xen-bus.c @@ -698,7 +698,8 @@ int xen_device_frontend_scanf(XenDevice *xendev, const char *key, } static void xen_device_frontend_set_state(XenDevice *xendev, - enum xenbus_state state) + enum xenbus_state state, + bool publish) { const char *type = object_get_typename(OBJECT(xendev)); @@ -710,7 +711,9 @@ static void xen_device_frontend_set_state(XenDevice *xendev, xs_strstate(state)); xendev->frontend_state = state; - xen_device_frontend_printf(xendev, "state", "%u", state); + if (publish) { + xen_device_frontend_printf(xendev, "state", "%u", state); + } } static void xen_device_frontend_changed(void *opaque) @@ -726,7 +729,7 @@ static void xen_device_frontend_changed(void *opaque) state = XenbusStateUnknown; } - xen_device_frontend_set_state(xendev, state); + xen_device_frontend_set_state(xendev, state, false); if (state == XenbusStateInitialising && xendev->backend_state == XenbusStateClosed && @@ -1169,7 +1172,7 @@ static void xen_device_realize(DeviceState *dev, Error **errp) xen_device_frontend_printf(xendev, "backend-id", "%u", xenbus->backend_id); - xen_device_frontend_set_state(xendev, XenbusStateInitialising); + xen_device_frontend_set_state(xendev, XenbusStateInitialising, true); xendev->exit.notify = xen_device_exit; qemu_add_exit_notifier(&xendev->exit);