[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.