Re: [Xen-devel] [PATCH 3/6] x86/cpuid: Move all xstate leaf handling into guest_cpuid()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/01/17 16:58, Jan Beulich wrote:
>>>> On 16.01.17 at 12:40, <andrew.cooper3@xxxxxxxxxx> wrote:
>> @@ -1007,10 +864,13 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>>              break;
>>  
>>          case XSTATE_CPUID:
>> -            if ( subleaf > ARRAY_SIZE(p->xstate.raw) )
>> +            if ( !p->basic.xsave || subleaf >= ARRAY_SIZE(p->xstate.raw) )
>>                  return;
>>  
>> -            /* Fallthrough. */
>> +            BUG_ON(subleaf >= ARRAY_SIZE(p->xstate.raw));
> Kind of pointless considering the if() right above? With this removed
> (or the reason for it clarified)
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

It was for consistency with the other raw[] accesses, but given this
subleaf calculation, I can drop it.

>
>> @@ -1067,6 +927,31 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
>>              break;
>>          }
>>          break;
>> +
>> +    case XSTATE_CPUID:
>> +        switch ( subleaf )
>> +        {
>> +        case 1:
>> +            if ( p->xstate.xsaves )
>> +            {
>> +                /*
>> +                 * TODO: Figure out what to do for XSS state.  VT-x manages
>> +                 * host vs guest MSR_XSS automatically, so as soon as we 
>> start
>> +                 * supporting any XSS states, the wrong XSS will be in
>> +                 * context.
>> +                 */
>> +                BUILD_BUG_ON(XSTATE_XSAVES_ONLY != 0);
> Yeah, I guess we won't have many options other than switching
> XSS around for the CPUID invocation.

The other option is to have a function which takes xcr0|xss and performs
some calculations with xstate_{offsets[],sizes[],align}, which might
plausibly be faster than switching MSR_XSS.  Either way, this isn't a
problem I want to solve until I have a real piece of hardware using XSS
states to develop against.

~Andrew

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