Re: [Xen-devel] [PATCH v4 10/17] x86emul: add tables for 0f38 and 0f3a extension space

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.03.17 at 16:49, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 28/02/17 12:54, Jan Beulich wrote:
>> @@ -340,6 +342,28 @@ static const struct {
>>      [0xff] = { ModRM }
>>  };
>>  
>> +static const struct {
>> +    uint8_t simd_size:5;
>> +    uint8_t to_memory:1;
> 
> Depending on how often it is used, what about shortening to "to_mem"? 
> It is no less clear.

No problem.

>> @@ -2740,6 +2790,13 @@ x86_decode(
>>          break;
>>  
>>      case ext_0f3a:
>> +        d = ext0f3a_table[b].to_memory ? DstMem | SrcReg : DstReg | SrcMem;
>> +        if ( ext0f3a_table[b].two_op )
>> +            d |= TwoOp;
>> +        else if ( ext0f3a_table[b].four_op && !mode_64bit() && vex.opcx )
>> +            imm1 &= 0x7f;
> 
> Is this sensible to do?  The behaviour of imm1 doesn't appear to be very
> consistent across encodings.  As it is all passed onto hardware anyway
> via stub, does it really matter?

Oh, yes, it does matter: We're running in 64-bit mode, and the high
bit, when representing a register, is ignored outside of 64-bit mode.
If we didn't mask it off, we'd access the wrong register if 32- or 16-
bit code had the bit set.

Jan


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