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@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?