[libvirt] [PATCH 09/10] libxl: Stubdom emulator type
Marek Marczykowski-Górecki
marmarek at invisiblethingslab.com
Wed Mar 4 19:02:25 UTC 2015
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 at 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150304/309cf3f4/attachment-0001.sig>
More information about the libvir-list
mailing list