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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 6 Feb 2015, 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.
> 
> >> diff --git a/stubdom-linux/qemu-xen-h.patch 
> >> b/stubdom-linux/qemu-xen-h.patch
> >> new file mode 100644
> >> index 0000000..262b1d1
> >> --- /dev/null
> >> +++ b/stubdom-linux/qemu-xen-h.patch
> >> @@ -0,0 +1,18 @@
> >> +--- a/include/hw/xen/xen.h   2015-01-21 23:54:36.856666662 -0500
> >> ++++ b/include/hw/xen/xen.h   2015-01-21 23:55:39.356666667 -0500
> >> +@@ -28,6 +28,15 @@
> >> +     return xen_allowed;
> >> + }
> >> +
> >> ++static inline int xen_stubdom_enable(void)
> >> ++{
> >> ++#ifdef CONFIG_STUBDOM
> >> ++    return 1;
> >> ++#else
> >> ++    return 0;
> >> ++#endif
> >> ++}
> >
> > As the STUBDOM related changes are small, I think we could avoid to
> > introduce this config option altogether.
> >
> > Maybe we could figure out that we are running as stubdom with a runtime
> > option, like a command line argument, something on xenstore or even our
> > own domain id.
> 
> I will have to check - there may have been other preexisting uses of
> CONFIG_STUBDOM is QEMU-upstream that might further encourage its use.
> I'm also not sure if we get much benefit out of doing runtime checks
> instead of ifdef's, since I think we'll end up having to do a separate
> build of QEMU for stubdom anyways.
 
The benefit would be avoiding the introduction of CONFIG_STUBDOM as the
QEMU community might not be too keen on it. But it is worth a try.

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