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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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