Re: [Xen-devel] A couple of HVMlite loose ends

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.01.16 at 16:49, <roger.pau@xxxxxxxxxx> wrote:
> Hello,
> 
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
> 
> 1. HVM CPUID and Dom0.
> 
> Sadly the way CPUID is handled inside of Xen varies between PV and HVM.
> On PV guests AFAICT we mostly do black-listing (I think this is the
> right term), which means we pick the native CPUID result and then
> perform a series of filter operations in order to remove features which
> should not be exposed to a PV guest. On the other hand, for HVM guests
> we pre-populate an array (d->arch.cpuids) during domain build time, and
> the contents of that array is what is returned to the guest when a CPUID
> instruction is executed.

This d->arch.cpuids[] mechanism is common to HVM and PV; the
exception really is Dom0.

> This is a problem for a HVMlite Dom0, since the code that populates this
> array resides in libxc, and when creating a HVMlite Dom0 from Xen itself
> (using a properly arranged Dom0 builder) this array doesn't get
> populated at all, leading to wrong CPUID information being returned to
> the guest. I can see two solutions to this problem:
> 
>  a) Switch CPUID handling for HVMlite Dom0 to the PV one, like it's done
> for PVH Dom0.

I think this is what needs to be done for the time being, unless ...

>  b) Duplicate the code in libxc into the Xen HVMlite Dom0 builder and
> populate d->arch.cpuids.

... this would be done by source code sharing.

Jan


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