Re: [PULL 13/27] hw/xen: Add xenstore operations to allow redirection to internal emulation

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]

On Sun, 2023-03-12 at 15:19 -0400, Jason Andryuk wrote:
> 
> This breaks dm_restrict=1 since the xs_open is not allowed by the
> time
> this is called.  There are other evtchn errors before this as well:
> # cat /var/log/xen/qemu-dm-debian.log
> char device redirected to /dev/pts/8 (label serial0)
> xen be core: can't open evtchn device
> xen be core: can't open evtchn device
> xen be core: can't open evtchn device
> xen be core: can't open evtchn device
> xen be core: can't open evtchn device
> xen be core: can't open evtchn device
> xen be core: can't open evtchn device
> xen be core: can't open evtchn device
> Could not contact XenStore
> 
> Ok, those "xen be core: can't open evtchn device" were there before
> the recent changes and seem to be non-fatal.

Hm, I *think* we can just revert that part and use the global
'xenstore' like we did before, except via the new ops.

--- a/accel/xen/xen-all.c
+++ b/accel/xen/xen-all.c
@@ -32,28 +32,18 @@ xendevicemodel_handle *xen_dmod;
 
 static void xenstore_record_dm_state(const char *state)
 {
-    struct xs_handle *xs;
     char path[50];
 
-    /* We now have everything we need to set the xenstore entry. */
-    xs = xs_open(0);
-    if (xs == NULL) {
-        fprintf(stderr, "Could not contact XenStore\n");
-        exit(1);
-    }
-
     snprintf(path, sizeof (path), "device-model/%u/state", xen_domid);
     /*
      * This call may fail when running restricted so don't make it fatal in
      * that case. Toolstacks should instead use QMP to listen for state changes.
      */
-    if (!xs_write(xs, XBT_NULL, path, state, strlen(state)) &&
+    if (!qemu_xen_xs_write(xenstore, XBT_NULL, path, state, strlen(state)) &&
             !xen_domid_restrict) {
         error_report("error recording dm state");
         exit(1);
     }
-
-    xs_close(xs);
 }
 
 
Alternatively, that xs_write is destined to fail anyway in the
xen_domid_restrict case, isn't it? So the xs_open() should be allowed
to fail similarly. Or perhaps we shouldn't even *try*?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]