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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 11/16/2016 12:34 PM, Andrew Cooper wrote:
> 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?

I don't think it changes anything wrt clearing eax on Intel.

-boris

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