[libvirt] [PATCH 09/10] libxl: Stubdom emulator type

[Marek Marczykowski-Górecki]

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>