Re: [Xen-devel] [PATCH 3/4 V3] X86: MPX IA32_BNDCFGS msr handle

[Tim Deegan <tim@xxxxxxx>]

At 03:17 +0000 on 28 Nov (1385605079), Liu, Jinsong wrote:
> Andrew Cooper wrote:
> > On 27/11/13 15:02, Liu, Jinsong wrote:
> >> Andrew Cooper wrote:
> >>> It is very common to have pools of servers made of different
> >>> generations of CPU.  E.g. Ivy Bridge and Haswell.  To safely migrate
> >>> a VM, the feature set the VM can see must be the common subset of
> >>> the two. 
> >>> 
> >>> ~Andrew
> >> Yes -- but that's not a reason to prevent MPX feature (or, any new
> >> features) -- otherwise you have to prevent any new features. 
> >> The right place to control cpuid policy of a pool is at higher
> >> level, where it has full information of the pool machines and so
> >> it's right place to make decision what cpuid feature set would be
> >> proper for the specific pool.   
> >> 
> > That is exactly a reason to prevent MPX.
> > 
> > If the domain cpuid policy (which is set by the toolstack) states that
> > MPX should be disabled, then MPX must be hidden from the HVM guest,
> > even if the hardware supports MPX.
> 
> No. That's _not_ a reason to prevent MPX -- toolstack still has the
> right to disable MPX, no matter h/w support MPX or not. Refer
> xc_cpuid_set().

There seems to be a lot of confusion here.  As far as I can tell, the
only sensible mechanism is:

- If the hardware doesn't support MPX, mask it in guest CPUID.
- If the domain cpuid policy masks the MPX feature, disable it.
- Otherwise, enable it, and advertise it in guest CPUID.

In any case, the CPUID fields seen by the guest _must_ match whether
the feature is available.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel