Re: [Xen-devel] [PATCH v4 5/6] libxl: add options to enable/disable emulated devices

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 21/01/16 a les 17.51, Roger Pau Monne ha escrit:
> Allow enabling or disabling emulated devices from the libxl domain
> configuration file. For HVM guests with a device model all the emulated
> devices are enabled. For HVM guests without a device model no devices are
> enabled by default, although they can be enabled using the options provided.
> The arbiter of whether a combination is posible or not is always Xen, libxl
> doesn't do any kind of check.
> 
> This set of options is also propagated inside of the libxl migration record
> as part of the contents of the libxl_domain_build_info struct, so that when
> the other end (restore) creates the domain the same set of devices are
> enabled. This is important for future compatibility, in case we decide to
> enable some emulated devices by default for HVMlite guests, old HVMlite
> guests migrated to newer versions should continue to see the same set of
> emulated devices.
> 
> It has been discussed that it would be better to avoid having this
> information inside of the libxl stream, and to instead rely on which devices
> get their context loaded inside of Xen on resume. This of course requires
> more work and it also has certain issues, like the fact that some devices
> don't restore a context at all (like VGA). The consensus is that the
> solution presented in this patch is not going to prevent further
> developments in this direction, and can always be used as a check to make
> sure the Xen context and the libxl context are in sync.
> 
> Signed-off-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
> ---
> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>

To tools committers: please refrain from pushing this until we have a
clear view on which devices we might want to enable in the future.
Adding a bunch of libxl options that are never going to be allowed
doesn't make any sense.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel