Re: [Xen-devel] [PATCH v3 07/18] x86emul: support {,V}{LD,ST}MXCSR

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.02.17 at 15:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 15/02/17 11:11, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -6183,6 +6200,23 @@ x86_emulate(
>>      case X86EMUL_OPC(0x0f, 0xae): case X86EMUL_OPC_66(0x0f, 0xae): /* Grp15 
>> */
>>          switch ( modrm_reg & 7 )
>>          {
>> +        case 2: /* ldmxcsr */
>> +            generate_exception_if(vex.pfx, EXC_UD);
>> +            vcpu_must_have(sse);
>> +        ldmxcsr:
>> +            generate_exception_if(src.type != OP_MEM, EXC_UD);
>> +            generate_exception_if(src.val & ~mxcsr_mask, EXC_GP, 0);
>> +            asm volatile ( "ldmxcsr %0" :: "m" (src.val) );
>> +            break;
>> +
>> +        case 3: /* stmxcsr */
>> +            generate_exception_if(vex.pfx, EXC_UD);
>> +            vcpu_must_have(sse);
>> +        stmxcsr:
>> +            generate_exception_if(dst.type != OP_MEM, EXC_UD);
>> +            asm volatile ( "stmxcsr %0" : "=m" (dst.val) );
>> +            break;
>> +
>>          case 5: /* lfence */
>>              fail_if(modrm_mod != 3);
>>              generate_exception_if(vex.pfx, EXC_UD);
>> @@ -6226,6 +6260,20 @@ x86_emulate(
>>          }
>>          break;
>>  
>> +    case X86EMUL_OPC_VEX(0x0f, 0xae): /* Grp15 */
>> +        switch ( modrm_reg & 7 )
>> +        {
>> +        case 2: /* vldmxcsr */
>> +            generate_exception_if(vex.l || vex.reg != 0xf, EXC_UD);
>> +            host_and_vcpu_must_have(avx);
> 
> If you move the {ld,st}mxcsr labels up by one, these can reduce to just
> vcpu_must_have(avx), as we don't use the VEX encoded variant.

Nice idea, and I'll drop the host_and_ part for sure, but moving up
the labels is neither needed, nor would it help.

> Having said that, shouldn't the pfx check be included even in the
> VEX-encoded case?  (i.e. the lables move up once again).

It's the other way around actually: The checks are redundant in
the non-VEX case, as the prefix is included in the opcode (see the
handling of 0xae in x86_decode_twobyte()).

Jan


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