Re: A couple of HVMlite loose ends

[Juergen Gross <jgross@suse.com>]

On 13/01/16 16:49, Roger Pau Monné 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 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.
> 
>  b) Duplicate the code in libxc into the Xen HVMlite Dom0 builder and
> populate d->arch.cpuids.

Make this "move the code from libxc into xen/common/lib<blah> and use
the code from libxc and the hypervisor".

> I'm leaning towards option "b)", because I would like HVMlite to behave
> as a HVM guest as much as possible, but I would like to hear opinions
> from others before taking either route.

I'd prefer the modified b) version, too.

> 2. HVM MTRR and Dom0.
> 
> MTRR ranges are initialised from hvmloader, which means that although we
> expose the MTRR functionality to HVMlite guests (and AFAICT the
> functionality is fully complete/usable), the initial state in which a
> guest finds the MTRR ranges is not expected, leading to errors. Again, I
> see three ways to solve this:
> 
>  a) Mask the MTRR functionality from CPUID for HVMlite guests. This
> requires adding a XEN_X86_EMU_MTRR flag to the bitmap introduced in arch
> domain.
> 
>  b) Setting up the initial MTRR state from libxl/libxc for HVMlite DomU
> and from the Xen domain builder for HVMlite Dom0. This again implies
> some functional duplication of MTRR related code, since now we would
> have 3 different places where MTRR is setup. One inside hvmloader for
> classic HVM guests, another one inside of libxl/libxc for HVMlite DomU
> and yet another one in the Dom0 building for HVMlite Dom0.

Same as above.

> 
>  c) Be aware of this fact and change the OS code so that it will setup
> the initial MTRR ranges correctly.
> 
> Again, I'm leaning towards "b)", because that's the one that's closest
> to native and what we do for classic HVM guests, but would like to hear
> opinions.

And again as above. :-)


Juergen