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

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

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'.

Thanks,
Jinsong

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