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@xxxxxxxxxxxxxxxxxxxxxx> > > > --- > > > > > > 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?
Attachment:
pgpIxkSlymPZF.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list