Re: [PATCH v3 09/28] xen/x86: Calculate maximum host and guest featuresets

["Jan Beulich" <JBeulich@suse.com>]

>>> On 22.03.16 at 15:37, <andrew.cooper3@citrix.com> wrote:
> On 22/03/16 12:39, Jan Beulich wrote:
>>>>> On 22.03.16 at 12:23, <andrew.cooper3@citrix.com> wrote:
>>> On 18/03/16 17:09, Jan Beulich wrote:
>>>>>>> On 15.03.16 at 16:35, <andrew.cooper3@citrix.com> wrote:
>>>>> +static void __init calculate_hvm_featureset(void)
>>>>> +{
>>>>> +    unsigned int i;
>>>>> +    const uint32_t *hvm_featuremask;
>>>>> +
>>>>> +    if ( !hvm_enabled )
>>>>> +        return;
>>>>> +
>>>>> +    hvm_featuremask = hvm_funcs.hap_supported ?
>>>>> +        hvm_hap_featuremask : hvm_shadow_featuremask;
>>>> I know I asked about this before, and it still puzzles me. Could you
>>>> add some explanation of this to the commit message or a comment?
>>> I am not sure what more I can say about it.
>>>
>>> The toolstack needs the be able to see the difference between a guest
>>> started in shadow mode on hap hardware, to be able to correctly
>>> calculate whether it can migrate to hap-incapable hardware. 
>> Difference to what? A HAP guest? How would that difference be
>> invisible if you surfaced two feature sets? Even more - with just
>> one feature set exposed, how would the tool stack see that very
>> difference?
> 
> At the moment, a toolstack creates a domain, and has no clue what the
> domain can actually see in cpuid.  In particular, it can't retrieve the
> "lost bits" which Xen dynamically disables.

One more reason to expose the shadow and HAP feature sets
separately, it would seem to me. Then the tool stack can have
a clue.

Jan

> As a result, creating a shadow domain on a hap-capable host results in
> misinformation about which features the guest was advertised at boot. 
> This in turn leads to an erronious decision that the domain can't be
> migrated to a hap-incapable host.
> 
>>
>>> There is no "get_cpuid_policy" hypercall, so a toolstack cannot query
>>> what a guest can actually see, after Xen's dynamic checks have taken place.
>>>
>>> Implementing get_cpuid_policy depends on Xen having a full model of
>>> cpuid state, which is too much work to be rolled together into this series.
>>>
>>> Like all of the dynamic checks later, it is only an intermediate step,
>>> and I do have plans to remove them longterm when Xen has a better model
>>> of cpuid.
>> I understand this is subject to further changes down the road. But
>> we all know that getting there may take time, so getting things
>> right for the time until then is quite necessary (the more that we're
>> going to release 4.7 in such intermediate state aiui).
> 
> This is all an internal implementation detail.  It (very deliberately)
> doesn't manifest in the public API.
> 
> It exists only internally to Xen, and in the libxc wrapper exposing the
> autogenerated information.
> 
> ~Andrew




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