[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] A couple of HVMlite loose ends
On 01/13/2016 11:30 AM, Andrew Cooper wrote: 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. We don't use CPUID to only turn on and off features. It also, for example, describes topology -- something that we may use one day (possibly for dom0 too). -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |