[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 16:26, Jan Beulich wrote: >>>> On 13.01.16 at 17:17, <andrew.cooper3@xxxxxxxxxx> wrote: >> On 13/01/16 16:13, Jan Beulich wrote: >>>>>> 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. >> Dom0 is not special when it comes to cpuid, and shouldn't be treated as >> such. My longter term CPUID plans will be fixing this. > In some way it is - there's no need for hiding features from it, since > it can't be migrated. Thats perfectly fine and normal. The same applies to all other domains which wont migrate, or will only migrate to identical hardware. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |