Re: [libvirt] [PATCH 09/10] libxl: Stubdom emulator type
On Thu, Feb 19, 2015 at 10:19:22PM +0100, Marek Marczykowski-Górecki wrote:
On Thu, Feb 19, 2015 at 01:45:52PM -0700, Jim Fehlig wrote:
> Marek Marczykowski-Górecki wrote:
> > Xen have feature of having device model in separate domain (called stub
> > domain). Add a 'type' attribute to 'emulator' element to allow
selecting
> > such a configuration.
>
> Or maybe 'mode', describing the mode in which the emulator runs: as a
> process or as a VM.
>
> > Emulator path is still used for qemu running in dom0 (if
> > any). Libxl currently do not allow to select stubdomain path.
> >
>
> That seems to overload a single <emulator>. Would it be better to have
> multiple <emulators>? E.g.
>
> <emulator>/usr/lib/xen/bin/qemu-system-i386</emulator>
> <emulator
mode='stubdomain'>/usr/lib/xen/bin/stubdom-dm</emulator>
So the existence of <emulator mode='stubdomain'/> would enable this
feature?
What if someday the default will be to run stubdomain emulator - how
the user can disable it in such case?
Any thoughts here? I can simply implement your proposition and not worry
about disabling stubdom emulator (as in no case it is enabled by
default, *for now*).
Or another idea - you can not use the same binary as either process or
stubdomain, so maybe it would be better to introduce separate element,
instead or reusing <emulator>? Plain <stubdomain>? Or <emustubdomain>?
In this case also capabilities XML would be easier to understand.
I want to sent next iteration of this patch series (I've already handled
other issues). Or maybe should I split stubdomain out of this series and send
what I have ready for now?
> > Signed-off-by: Marek Marczykowski-Górecki
<marmarek(a)invisiblethingslab.com>
> > ---
> >
> > I think it would be good idea to introduce the same change to capabilities
XML.
> > The problem is I can't include domain_conf.h from capabilities.h, so
probably
> > that enum declaration needs to be moved to capabilities.h. Is it the right
way?
> > Or it should be done somehow different?
Any hints here? IMHO it would be hardly useful without mentioning
possible values in capabilities XML...
In case of multiple <emulator>s, should them be just listed (possible
values), or the whole possible combinations (which 'process' emulator
with which 'stubdomain' one if applicable)? I think the later option is
better.
In case of new element instead of reused <emulator>, this problem would
be much easier to solve.
(...)
> > + /* In case of stubdom there will be two qemu
instances:
> > + * - in stubdom (libxl uses hardcoded path for this one),
> > + * - in dom0 as a backend for stubdom (if needed).
> >
>
> Your comment here provoked my thinking above about supporting multiple
> <emulator>s. ISTM there should be an <emulator> device for each of
> these qemu instances.
>
> > + * Emulator path control only the second one. It makes a perfect
sense
> > + * to use <emulator type='stubdom'/> (yes, without
emulator path).
> >
>
> I'm not so sure. Maybe we should first add support in libxl for
> specifying a stubdomain emulator path.
Yes, this would be a good idea (especially when someone implements
alternative stubdomain emulator). But Xen <=4.5 still should be somehow
handled - I think it can be plain <emulator mode='stubdomain'/> (without
a path). Possibly rejecting a path if not supported by underlying libxl.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Attachments:
- attachment.sig (application/pgp-signature — 473 bytes)