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

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

El 21/01/16 a les 11.29, Ian Campbell ha escrit:
> On Thu, 2016-01-21 at 11:01 +0100, Roger Pau Monnà wrote:
>> El 21/01/16 a les 10.39, Ian Campbell ha escrit:
>>>> It also means that HVMlite guests created with current Xen will be
>>>> capable of migrating to newer version of Xen, that might have a
>>>> different default policy. For example in the future we might want to
>>>> enable the lapic by default, so if a guest is created with the current
>>>> Xen version it doesn't get a lapic at all, and then when migrated to
>>>> newer versions a lapic would magically appear after the migration, which
>>>> is not desired.
>>>
>>> ... and the reason these details can't be propagated via the Xen blob is
>>> that this emul stuff needs to be set exactly once at domain create time I
>>> suppose? Changing it to be later binding is considered to be too hard/too
>>> big a yak?
>>
>> Right, emulated devices are initialised as part of the 
>> XEN_DOMCTL_createdomain hypercall. Allowing them to be added later on 
>> and introducing a kind of intermediate domain building phase where only 
>> a certain set of hypercalls are valid is a possibility that Andrew 
>> already pointed out, however this seems like a very big project.
> 
> This seems like the right approach to me, but I appreciate you not wanting
> to tackle this here and now.
> 
> Would it be possible to set the set of "potential" emulated devices at
> create time and only "commit" to it after the save state is loaded? That
> would essentially mean init-all, load state, de-init those which didn't get
> any state loaded? Not as nice as doing it with the split of hypercall
> availability, but might be more achievable, since you already have the de-
> init code for domain teardown time.

Sadly there are devices that AFAICT don't restore any state (like the
VGA), which means a more complex mechanism is needed and we cannot rely
exclusively on restores in order to decide if a device is present or not.

IMHO the current approach is not that bad, and I think we should be able
to migrate to a better one without problems. If in the future we want to
do something like what you describe above (setting the set of emulated
devices based on the Xen context restored), the extra information in the
libxl JSON stream is certainly not going to hurt us. At worst we could
always check that the libxl JSON information matches with what the
hypervisor context contains for extra safety.

> In any case, whatever is chosen as the solution the commit message needs to
> go into a fair amount of detail as to why we picked that way of doing
> things, particularly if it is a compromise vs doing it properly.
> 
> This is important so we can answer "why did we do it this way" in 2 years
> time.

Right, thanks, I will update the commit message with the outcome of this
discussion.

Roger.


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