[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.