Re: [Xen-devel] [PATCH] x86/cpuid: Move vendor/family/model information from arch_domain to cpuid_policy

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/01/17 13:40, Jan Beulich wrote:
>>>> On 12.01.17 at 13:32, <andrew.cooper3@xxxxxxxxxx> wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -78,12 +78,11 @@ static void update_domain_cpuid_info(struct domain *d,
>>      switch ( ctl->input[0] )
>>      {
>>      case 0: {
>> -        int old_vendor = d->arch.x86_vendor;
>> +        int old_vendor = p->x86_vendor;
>>  
>> -        d->arch.x86_vendor = get_cpu_vendor(
>> -            ctl->ebx, ctl->ecx, ctl->edx, gcv_guest);
>> +        p->x86_vendor = get_cpu_vendor(ctl->ebx, ctl->ecx, ctl->edx, 
>> gcv_guest);
>>  
>> -        if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
>> +        if ( is_hvm_domain(d) && (p->x86_vendor != old_vendor) )
>>          {
>>              struct vcpu *v;
>>  
>> @@ -95,7 +94,7 @@ static void update_domain_cpuid_info(struct domain *d,
>>      }
>>  
>>      case 1:
>> -        d->arch.x86 = get_cpu_family(ctl->eax, &d->arch.x86_model, NULL);
>> +        p->x86_family = get_cpu_family(ctl->eax, &p->x86_model, NULL);
>>  
>>          if ( is_pv_domain(d) && ((levelling_caps & LCAP_1cd) == LCAP_1cd) )
>>          {
> Considering that the three fields can be calculated from other
> CPUID data, is it really worthwhile to store these redundant pieces
> of information, instead of having consumers simply call
> get_cpu_{vendor,policy}()? All we "gain" by storing them is the risk
> of them going out of sync.

x86_model isn't actually used anywhere.  x86_family is only used in
hvm_select_ioreq_server() when handling AMD extended config space.

x86_family however is used quite a lot (all paths into x86_emulate(),
and the IOREQ infrastructure underneath).

I did make get_cpu_vendor() quite a lot better than it was previously,
but it is still searching a loop.  For the extra 3 bytes of data, I
still think pre-calculating the values is worth it.

~Andrew

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