Re: [Xen-devel] [PATCH 2/4] x86/cpuid: Store the toolstacks choice of hypervisor max leaf

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/01/17 11:32, Jan Beulich wrote:
>>>> On 11.01.17 at 18:44, <andrew.cooper3@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -136,6 +136,14 @@ static int update_domain_cpuid_info(struct domain *d,
>>              p->basic.raw[ctl->input[0]] = leaf;
>>          break;
>>  
>> +    case 0x40000000:
>> +        p->hv_limit = ctl->eax;
>> +        break;
>> +
>> +    case 0x40000100:
>> +        p->hv2_limit = ctl->eax;
>> +        break;
> Generally the patch is fine, but do we really need to store two limits
> here?

Currently yes, because that is the ABI the toolstack expects.

> Can't we rely on the Viridian flag to be set first, so we could
> use it here?

You objected to implicit assumptions like this before.  I think it might
be safe given the current ordering in libxl and xenguest, but...

> And if indeed we can't right now, should it not be made so as a first step?

.. I plan to rework this all differently when altering the toolstack
half of CPUID.

Several Viridian and Xen fields work like plain feature words, and I
want the toolstack to control those in the same manner as other CPUID
information, even down to selecting which APIs/ABIs to make visible by
choosing the entirety of leaf 0x40000x00.  In particular, this gives us
a debugging mechanism previously lacking to actually hide the Xen leaves
entirely (We are the only hypervisor which doesn't have this option).

For now, I'd prefer to avoid making unnecessary toolstack changes.

~Andrew

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