Re: [Xen-devel] CPUID improvements (phase 2) Design Doc

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/11/16 08:31, Jan Beulich wrote:
>>>> On 08.11.16 at 19:36, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 08/11/16 16:32, Jan Beulich wrote:
>>>>>> On 08.11.16 at 16:35, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> Please find inline the design doc for further CPUID improvements, planned 
>>>> for
>>>> development during the 4.9 timeframe.
>>> Looks good, just a couple of minor remarks.
>>>
>>>> ## Changes in hypercall behaviour
>>>>
>>>> During domain construction, some pieces of information critical to the
>>>> determination of the domains maximum acceptable CPUID policy are available
>>>> right from the very start (Most notably, the HVM and HAP flags from the
>>>> `XEN_DOMCTL_createdomain`).
>>>>
>>>> However, some other parameters are not available at convenient points.
>>>>
>>>> 1.  The disable flag from `XEN_DOMCTL_disable_migrate` is used to set
>>>>     `d->disable_migrate`, whose only purpose is to avoid the unconditional
>>>>     clobbering of the Invariant TSC flag.  This flag cannot even be 
>>>> queried by
>>>>     the toolstack once set.
>>>>
>>>>     There are other facilities which should be restricted based on whether 
>>>> a
>>>>     VM might migrate or not.  (e.g. The use of LBR, whose record format is
>>>>     hardware specific.)
>>> Not really - the LBR format only limits the set of hosts the VM can
>>> migrate to. I.e. this is just like a CPUID flag which needs to be set
>>> on the target host in order for the VM to be permitted to migrate
>>> there.
>> It is more complicated than that.  The LBR format also depends on
>> whether TSX is enabled or not, which on Haswell-WS CPUs depends on
>> whether hyperthreading is enabled.
> Yes, but is this relevant? It's still only a value (identifying the format)
> which needs to match between source and destination hosts. I.e. not
> different from individual feature bits, just that here we're dealing with
> a multi-bit entity.

LBR format is controlled by IA32_PERF_CAPABILITIES[5:0], which I will
eventually get to covering with MSR levelling, with this being a
strictly non-levelable field.

Users' expectations when migrating a VM is that it should be able to go
anywhere.  In practice, this is only insofar as we can maintain
compatibility.  We should default to being as compatible as possible; if
a user asks for both migrateable and LBR, then thats fine as it comes
with an understanding of reduced mobility.

~Andrew

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