Re: [Xen-devel] [DESIGN] Feature Levelling improvements

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/06/15 16:09, Konrad Rzeszutek Wilk wrote:
>>>>     * Leaf 0x00000007[ECX=0].EAX
>>>> * `mask_l7s0_ebx`
>>> Those 'l' look like '1' in the PDF.
>>>
>>> Can it be called something else?
>> If you can suggest a better name, yes.  As for now, these are the
>> variable names used in-tree (top of xen/arch/x86/cpu/amd.c)
> low?

Low what?  l7s0 means "leaf 7 subleaf 0" which is the most accurate
description of it, given no specific name in either the Intel or AMD
references.

>>
>>>
>>>> VCPU context switch
>>>> -------------------
>>>>
>>>> Xen shall be updated to lazily context switch all available masking
>>>> MSRs.  It
>>>> is noted that this shall incur a performance overhead if restricted
>>>> featuresets are assigned to PV guests, and _CPUID Faulting_ is not
>>>> available.
>>>>
>>>> It shall be the responsibility of the host administrator to avoid creating
>>>> such a scenario, if the performance overhead is a concern.
>>> .. and perhaps add warnings in the toolstack to tell the admin?
>> How and where would this surface?  xl/libxl is not designed to run the
>> system as a whole.
> Not sure. We have some code for silly NUMA configuration that tells the user
> when they are picking the wrong option.

Well yes.  If xl isn't going to block the creation attempt (and it
absolutely shouldn't), this is something better left to some sort of
"host health check".

>>>> Future work
>>>> ===========
>>>>
>>>> The above is a minimum quantity of work to support feature levelling, but
>>>> further problems exist.  They are acknowledged as being issues, but are
>>>> not in
>>>> scope for fixing as part of feature levelling.
>>>>
>>>> * Xen has no notion of per-cpu and per-package data in the cpuid policy.  
>>>> In
>>>>   particular, this causes issues for VMs attempting to detect topology,
>>>> which
>>>>   find inconsistent/incorrect cache information.
>>>>
>>>> * In the case that `domain_cpuid()` can't locate a leaf in the topology, it
>>>>   will fall back to issuing a plain `CPUID` instruction.  This breaks VM
>>>>   encapsulation, as a VM which has migrated can observe differences which
>>>>   should be hidden.
>>>>
>>>> * There is currently a positioning issue with the domains cpuid policy.
>>>>   Verifying the register state requires the policy, but the policy is 
>>>> behind
>>>>   the register state in the migration stream.  The domains cpuid policy
>>>> should
>>>>   become an item in Xen's migration state for a VM.
>>> And potentially code in libxl to allow subset manipulation to allow
>>> leveling across different platforms. As in the common features would
>>> be exposed while all the other ones are masked? And I suppose some
>>> format to stash this so it can be ingested by the libxl tools?
>> libxl's knowledge of multiple platforms is precisely nothing.  xl knows
>> just enough to ssh and set up some pipes to push a VM through.
>>
>> The domain configuration does have cpuid information in it.  That will
> Does if 'cpuid' configuration is present?

Correct.

~Andrew

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