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*?
smime.p7s
Description: S/MIME cryptographic signature
