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

[Tim Deegan <tim@xxxxxxx>]

At 11:26 +0000 on 28 Nov (1385634381), Ian Campbell wrote:
> On Thu, 2013-11-28 at 12:14 +0100, Tim Deegan wrote:
> > At 11:12 +0000 on 28 Nov (1385633520), Liu, Jinsong wrote:
> > > Tim Deegan wrote:
> > > > 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.
> > > 
> > > Do you mean xc_cpuid_set() is some confusion? Yes, it's some buggy that 
> > > need got fix at tools side.
> > > 
> > > I take it here as an example just indicate 'toolstack has the right to 
> > > disable/mask hardware feature, if it want to do so per domain cpuid 
> > > policy'.
> > > 
> > 
> > In that case, I think you and Andrew are agreeing with each other. :)
> > The important detail is that if the toolstack has disabled the feature
> > using the CPUID policy, the hypervisor should not expose the feature
> > to the guest.
> 
> Do you mean expose as in "present in cpuid" or do you mean expose as in
> "the instructions/features work (even if disabled in cpuid)"?

I mean that if the guest does not see the feature in CPUID they should
net be able to use it.

Tim.

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