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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

> 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).

Jan


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