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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.03.16 at 16:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/03/16 14:52, Jan Beulich wrote:
>>>>> On 22.03.16 at 15:37, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> 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.
>> 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.
> 
> When "get_cpuid" works properly, it will no longer be needed, which is
> specifically why I am not putting it in the API.

This is a sysctl iirc, so not set in stone if added.

Jan

> The toolstack will be able to construct an arbitrary domain, call
> get_cpuid to see exactly what the guest will see, and use that as the
> basis of migrateability decisions.
> 
> It is just awkward that this information is needed at the moment when a
> suitable interface from Xen isn't available.
> 
> ~Andrew




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