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