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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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.


-boris


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