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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 01/03/17 16:11, Jan Beulich wrote:
>>>> 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.

Ok, but my first question still stands.

Across this entire series, the only .four_op instructions appear to be
the Vex blend instructions at 660f3a4{a,b,c}, and these are called out
as special cases in the instruction manual.

How does the above condition logically equate to "this instruction uses
its imm8 byte to encode an extra source register", because that is the
purpose of the applied mask.

~Andrew

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