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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/03/16 12:39, Jan Beulich wrote:
>>>> On 22.03.16 at 12:23, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 18/03/16 17:09, Jan Beulich wrote:
>>>>>> On 15.03.16 at 16:35, <andrew.cooper3@xxxxxxxxxx> 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.

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel