Re: [Xen-devel] [RFC 1/7] linux-stubdomain: Compile QEMU

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Feb 06, 2015 at 12:25:33PM -0500, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 10:46 AM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Tue, 3 Feb 2015, Eric Shelton wrote:
> 
> > Before having patches, I would like to try to get them upstream in QEMU.
> > If we really cannot do that, then I would still prefer to commit any
> > required workarounds to the qemu-xen rather than having them here as
> > patches.
> 
> Absolutely; the intent is to upstream the changes to QEMU, and
> eliminate the patching to QEMU being done in the patchset I sent out.
> I just need to sort out all of the QEMU changes first...
> 
> >> diff --git a/stubdom-linux/qemu-xen-common.patch 
> >> b/stubdom-linux/qemu-xen-common.patch
> >> new file mode 100644
> >> index 0000000..b473e36
> >> --- /dev/null
> >> +++ b/stubdom-linux/qemu-xen-common.patch
> >> @@ -0,0 +1,12 @@
> >> +--- a/xen-common.c   2015-01-25 20:42:36.329999998 -0500
> >> ++++ b/xen-common.c   2015-01-25 20:43:20.346666663 -0500
> >> +@@ -92,7 +92,8 @@
> >> +         exit(1);
> >> +     }
> >> +
> >> +-    snprintf(path, sizeof (path), "device-model/%u/state", xen_domid);
> >> ++    snprintf(path, sizeof (path),
> >> ++             "/local/domain/0/device-model/%u/state", xen_domid);
> >
> > Even if this counts as a workaround, I think it could go upstream in
> > QEMU.
> 
> Agreed, although I will likely follow Wei's suggestion to use a
> /local/domain/{stubdom-id}/... path, instead of under dom0's tree in
> xenstore.
> 

I guess if you don't use absolute path it should just writes to
/local/domain/$stubdom_id. (This has a restriction that it doesn't work
with xenstore connection opened with socket.)

Since you're at it, could you try to 

1) retain the relative path used here, so that it writes to ~ (from
   stubdom's PoV it is /local/domain/$stubdom_id, that's the theory)
2) modify patch 7/7 to use the /local/domain/$stubdom_id path.

My hunch is that it is not too complicated to retrieve stubdom_id in
libxl (it should be available somewhere).

A side note is that you may need to grant write permission the stubdom to
write to its own path. Search for XS_PERM_ in libxl_dm.c you will see
some place using "/local/domain/0".

That's what I would do to tackle this whole problem. I haven't tried it
personally though (got distracted half way).

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel