Re: [Xen-devel] [PATCH 4/6] x86/hvm: Move hvm_funcs.cpuid_intercept() handling into hvm_cpuid()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/11/16 17:34, Boris Ostrovsky wrote:
> On 11/16/2016 12:10 PM, Andrew Cooper wrote:
>> On 16/11/16 16:40, Boris Ostrovsky wrote:
>>> On 11/16/2016 07:31 AM, Andrew Cooper wrote:
>>>> @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int 
>>>> *eax, unsigned int *ebx,
>>>>  
>>>>          *ebx &= hvm_featureset[FEATURESET_e8b];
>>>>          break;
>>>> +
>>>> +    case 0x8000001c:
>>>> +        if ( !(v->arch.xcr0 & XSTATE_LWP) )
>>>> +            *eax = 0;
>>>> +        else if ( cpu_has_svm && cpu_has_lwp )
>>>> +            /* Turn on available bit and other features specified in 
>>>> lwp_cfg. */
>>>> +            *eax = (*edx & v->arch.hvm_svm.guest_lwp_cfg) | 1;
>>>> +        break;
>>>>      }
>>> You don't think this whole case should be under cpu_has_svm (or
>>> X86_VENDOR_AMD)?
>> LWP, being independently identifiable state should be gated on that
>> alone, even if in reality, it only exists on AMD hardware.
>>
>> The use of cpu_has_svm is only because guest_lwp_cfg is in an svm
>> union.  Were guest_lwp_cfg to move, the condition should be relaxed.
> I was thinking about the first 'if' clause. I believe 0x8000001c doesn't
> exist on Intel yet but if they add it we will clear eax for no good reason.
>
> OTOH we wouldn't be handling the leaf correctly anyway so maybe it's OK.

What do you think about Jan's suggestion, which is slightly better
overall anyway?

~Andrew

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