[Xen-devel] A couple of HVMlite loose ends

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

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.

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.

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.

 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.

Thanks, Roger.

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