Re: [Xen-devel] VM Feature levelling improvements proposal (draft C)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.02.14 at 17:22, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> How XenServer currently does levelling
> ======================================
> 
> The _Heterogeneous Pool Levelling_ support in XenServer appears to
> predate the
> libxc CPUID policy API, so does not currently use it.  The toolstack has a
> table of CPU model numbers identifying whether levelling is supported.  It
> then uses native `CPUID` instructions to look at the first four feature
> masks,
> and identifies the subset of features across the pool.
> `cpuid_mask_{,extd_}{ecx,edx}` is then set on Xen's command line for
> each host
> in the pool, and all hosts rebooted.
> 
> This has several limitations:
> 
> * Xen and dom0 have a reduced feature set despite not needing to migrate

Xen, at least for most features, doesn't, as it retrieves the feature
flags before applying the mask. Dom0 indeed is being limited without
need.

> * There is only a single level for all VMs in the pool
> * The toolstack only understands 4 of the 5 possible masking MSRs, and there
>   are now feature maps in further `CPUID` leaves which have no masking MSRs
> 
> 
> Proposal for new implementation
> ===============================

Sounds reasonable, but is of course in need of some details when
getting closer to actually implementing this. I'm in particular not
in favor of an approach where three more MSR writes would be
added to the (PV) context switch path (mostly) unconditionally.

Jan


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