[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] A couple of HVMlite loose ends
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |