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

[Eric Shelton <eshelton@xxxxxxxxx>]

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.

- Eric

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