Re: [Xen-devel] A couple of HVMlite loose ends

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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