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 21:35, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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:
>>>> @@ -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.

Well, "four_op" means four register operands (one of them
possibly also allowing for memory), just like two_op also doesn't
include possible immediates. "four_regs" would seem worse to
me, as that would be more along the lines of excluding memory
ones. I'll add a comment to this effect.

Jan


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