Re: [PATCH v4 2/6] xen: backends: don't overwrite XenStore nodes created by toolstack

2023-12-06 Thread Anthony PERARD
On Sat, Dec 02, 2023 at 01:41:21AM +, Volodymyr Babchuk wrote:
> Xen PV devices in QEMU can be created in two ways: either by QEMU
> itself, if they were passed via command line, or by Xen toolstack. In
> the latter case, QEMU scans XenStore entries and configures devices
> accordingly.
> 
> In the second case we don't want QEMU to write/delete front-end
> entries for two reasons: it might have no access to those entries if
> it is running in un-privileged domain and it is just incorrect to
> overwrite entries already provided by Xen toolstack, because toolstack
> manages those nodes. For example, it might read backend- or frontend-
> state to be sure that they are both disconnected and it is safe to
> destroy a domain.
> 
> This patch checks presence of xendev->backend to check if Xen PV
> device was configured by Xen toolstack to decide if it should touch
> frontend entries in XenStore. Also, when we need to remove XenStore
> entries during device teardown only if they weren't created by Xen
> toolstack. If they were created by toolstack, then it is toolstack's
> job to do proper clean-up.
> 
> Suggested-by: Paul Durrant 
> Suggested-by: David Woodhouse 
> Co-Authored-by: Oleksandr Tyshchenko 
> Signed-off-by: Volodymyr Babchuk 
> Reviewed-by: David Woodhouse 
> 

Hi Volodymyr,

There's something wrong with this patch. The block backend doesn't work
when creating a guest via libxl, an x86 hvm guest with qdisk.

Error from guest kernel:
"2 reading backend fields at /local/domain/0/backend/qdisk/23/768"

It seems that "sector-size" is missing for the disk.

Thanks,

-- 
Anthony PERARD



[PATCH v4 2/6] xen: backends: don't overwrite XenStore nodes created by toolstack

2023-12-01 Thread Volodymyr Babchuk
Xen PV devices in QEMU can be created in two ways: either by QEMU
itself, if they were passed via command line, or by Xen toolstack. In
the latter case, QEMU scans XenStore entries and configures devices
accordingly.

In the second case we don't want QEMU to write/delete front-end
entries for two reasons: it might have no access to those entries if
it is running in un-privileged domain and it is just incorrect to
overwrite entries already provided by Xen toolstack, because toolstack
manages those nodes. For example, it might read backend- or frontend-
state to be sure that they are both disconnected and it is safe to
destroy a domain.

This patch checks presence of xendev->backend to check if Xen PV
device was configured by Xen toolstack to decide if it should touch
frontend entries in XenStore. Also, when we need to remove XenStore
entries during device teardown only if they weren't created by Xen
toolstack. If they were created by toolstack, then it is toolstack's
job to do proper clean-up.

Suggested-by: Paul Durrant 
Suggested-by: David Woodhouse 
Co-Authored-by: Oleksandr Tyshchenko 
Signed-off-by: Volodymyr Babchuk 
Reviewed-by: David Woodhouse 

---

Changes in v4:
  - don't touch "tty" entry in the console backend

Changes in v3:
 - Rephrased the commit message
---
 hw/block/xen-block.c | 16 +---
 hw/net/xen_nic.c | 18 ++
 hw/xen/xen-bus.c | 14 +-
 3 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index c2ac9db4a2..dac519a6d3 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -390,13 +390,15 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 
 xen_device_backend_printf(xendev, "info", "%u", blockdev->info);
 
-xen_device_frontend_printf(xendev, "virtual-device", "%lu",
-   vdev->number);
-xen_device_frontend_printf(xendev, "device-type", "%s",
-   blockdev->device_type);
-
-xen_device_backend_printf(xendev, "sector-size", "%u",
-  conf->logical_block_size);
+if (!xendev->backend) {
+xen_device_frontend_printf(xendev, "virtual-device", "%lu",
+   vdev->number);
+xen_device_frontend_printf(xendev, "device-type", "%s",
+   blockdev->device_type);
+
+xen_device_backend_printf(xendev, "sector-size", "%u",
+  conf->logical_block_size);
+}
 
 xen_block_set_size(blockdev);
 
diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c
index afa10c96e8..27442bef38 100644
--- a/hw/net/xen_nic.c
+++ b/hw/net/xen_nic.c
@@ -315,14 +315,16 @@ static void xen_netdev_realize(XenDevice *xendev, Error 
**errp)
 
 qemu_macaddr_default_if_unset(&netdev->conf.macaddr);
 
-xen_device_frontend_printf(xendev, "mac", "%02x:%02x:%02x:%02x:%02x:%02x",
-   netdev->conf.macaddr.a[0],
-   netdev->conf.macaddr.a[1],
-   netdev->conf.macaddr.a[2],
-   netdev->conf.macaddr.a[3],
-   netdev->conf.macaddr.a[4],
-   netdev->conf.macaddr.a[5]);
-
+if (!xendev->backend) {
+xen_device_frontend_printf(xendev, "mac",
+   "%02x:%02x:%02x:%02x:%02x:%02x",
+   netdev->conf.macaddr.a[0],
+   netdev->conf.macaddr.a[1],
+   netdev->conf.macaddr.a[2],
+   netdev->conf.macaddr.a[3],
+   netdev->conf.macaddr.a[4],
+   netdev->conf.macaddr.a[5]);
+}
 netdev->nic = qemu_new_nic(&net_xen_info, &netdev->conf,
object_get_typename(OBJECT(xendev)),
DEVICE(xendev)->id, netdev);
diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index dd0171ab98..d0f17aeb27 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -599,8 +599,10 @@ static void xen_device_backend_destroy(XenDevice *xendev)
 
 g_assert(xenbus->xsh);
 
-xs_node_destroy(xenbus->xsh, XBT_NULL, xendev->backend_path,
-&local_err);
+if (!xendev->backend) {
+xs_node_destroy(xenbus->xsh, XBT_NULL, xendev->backend_path,
+&local_err);
+}
 g_free(xendev->backend_path);
 xendev->backend_path = NULL;
 
@@ -764,8 +766,10 @@ static void xen_device_frontend_destroy(XenDevice *xendev)
 
 g_assert(xenbus->xsh);
 
-xs_node_destroy(xenbus->xsh, XBT_NULL, xendev->frontend_path,
-&local_err);
+if (!xendev->backend) {
+xs_node_destroy(xenbus->xsh, XBT_NULL, xendev->frontend_path,
+&local_err);
+}
 g_free(xendev->frontend_path);
 xendev->fronten