Re: [Xen-devel] [PATCH RFC v1 00/74] Run PV guest in PVH container

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Ian Jackson writes ("Re: [Xen-devel] [PATCH RFC v1 00/74] Run PV guest in PVH 
container"):
> Xen 4.10
> ========
...
>  => code change: the backport should set the default non-NULL
>     values only if the pvhshim boolean is true after defaulting

I discover, looking at the code, that this is already true.

> New callers with old libxl on 4.10:
> -----------------------------------
> 
> If the caller is creating a guest other than a PVH one there is no
> change to the ABI.
> 
> When a caller creates a PVH non-shim guest, it will probably not set
> any of these fields.  Things will work properly.
> 
> If a caller tries to create a shim guest, the attempt to do so will be
> ignored and the guest will be created as PV.  Probably, the guest will
> not boot.  Additionally, if the caller filled in pvshim cmdline or
> path information, it will probably expect *dispose* to free those
> values - and the result will be a memory leak.
> 
> If the caller is examining existing guests, PV and HVM guests will
> work fine.  If the caller is examining existing PVH guests, the
> library will not initialise the new fields.  The result may include an
> uninitialised read by the caller.
> 
> Overall: this is not safe and should be prevented.
> 
>  => code change: the 4.10 backport should use symbol versioning or
>     another technique to prevent expecting callers whose source code
>     understands *shim* guests from using libxl versions which don't.

This is only _really_ needed to avoid trouble when:
  * New tool has been installed
  * New libxl has not been installed
  * PVH guests (including shim guests) have been created by tool A
  * Tool B has not been updated, and is used to examine guests

We do not have any symbol versioning in libxl in 4.10 and it is hard
to think of another way to make this work without changes to the tool
source code.  I don't want to invent something ad-hoc.

So I propose to skip this.

Wei: My conclusion is that the libxl tools branch (including George's
"libxl: introduce hack" patch, as I I sent you previously, is suitable
for simple rebase to 4.10.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel