[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/4 V3] X86: MPX IA32_BNDCFGS msr handle
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |