Re: [RFC 0/6] RFC Linux based stub-domain

[Anthony PERARD <anthony.perard@citrix.com>]

On 19/04/13 10:17, Ian Campbell wrote:
> On Wed, 2013-04-17 at 20:09 +0100, Anthony PERARD wrote:
>> Hi all,
>>
>> Here is the long overdue patch series to bring support for a Linux based
>> stubdom which will enable to use QEMU upstream as device model in a stubdom.
> 
> Thanks.
> 
> Do you have any performance figures?

Yes, I do. I've wrote a presentation for Xen Summit. I will dig them and
post them back.

> What are the overheads for the stub domain (e.g. memory)?

For memory, about 34MB for the domain, plus something (a process in
dom0) to read the stubdom disk image. I can't think of something else.


> The dependency on various non-mainline git repos and on out of tree
> patching are a bit concerning, how are we going to address those?

The patches for QEMU need to be upstreamed. Then, we could just use the
same tree as the non-stubdom qemu-xen, and decide later if it's usefull
to build QEMU twice.

For Linux patches, I'm not sure what to do.
 - One of them is about checking if a domain have right to call an
hypercall. To be upstream, we would need to check if indeed the
hypercall can be called from this domain, or maybe let the hypervisor do
this check.
 - There other one fix the an address when the function is called from
the stubdom. This one could works in any case.

> The hardcoded Linux version (currently 3.4.13) is also something of a
> concern -- what is the intended strategy for managing the kernel used
> here? Are we planning to periodically update it or something?

Well, I've start with this one, but I think that any last release could
work, provided the patch are upstream or can be applied.

> Is there any requirement to build as root?

No. The only one would be to build a disk image, but I found a way which
works on my system without running as root. But this use 'debugfs' to
write into a ext2 filesystem.

> This seems to add a dependency on /bin/busybox from the host, is there a
> configure check to ensure this is present? Do we rely on the distro to
> provide this? Which distros has it been tested on? Do we know that
> distros in general provide a package with /bin/busybox in it?

Busybox should be a dependency for the build host, which is probably
better than compiling it our self. The scripts does not really check for
it, yet.
There is another dependency, debugfs, which I'm not sure where we will
find it. But I think that I check in debian when I start using it.

Thanks,

-- 
Anthony PERARD