Re: [PATCH] x86: ignore high register select bit(s) in 32- and 16-bit modes

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 23.02.17 at 17:29, <hjl.tools@gmail.com> wrote:
> On Thu, Feb 23, 2017 at 8:16 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 23.02.17 at 16:54, <hjl.tools@gmail.com> wrote:
>>> On Wed, Feb 22, 2017 at 11:38 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 22.02.17 at 20:03, <hjl.tools@gmail.com> wrote:
>>>>> On Tue, Feb 21, 2017 at 8:27 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> @@ -16937,7 +16928,7 @@ OP_VEX (int bytemode, int sizeflag ATTRI
>>>>>>           names = names_xmm;
>>>>>>           break;
>>>>>>         case dq_mode:
>>>>>> -         if (vex.w)
>>>>>> +         if (rex & REX_W)
>>>>>>             names = names64;
>>>>>>           else
>>>>>>             names = names32;
>>>>>
>>>>> Do you have a testcase where vex.w != rex & REX_W?
>>>>
>>>> I'm sorry, but I don't think I understand the question in the light
>>>> of there being a testcase added covering all of the previous
>>>> misbehaviors I'm aware of.
>>>
>>> My question is why vex.w and rex & REX_W are out of sync
>>> at this point.
>>
>> That's because for 64-bit code REX_W gets ser from vex.w
>> during VEX decoding. For 16- and 32-bit code this doesn't happen,
>> and hence looking at vex.w (possibly set) is wrong here, while
> 
> vex.w must be set correctly.  Can you show me where it is set
> incorrectly?

I don't understand the request. vex.w is set correctly (reflecting
what the instruction had), but it mustn't be used in certain cases.

> For GPR instructions with VEX/EVEX encoding in 16/32 bit mode,
> if vex.w is ignored, it shouldn't matter.  If it isn't ignored, it should 
> UD.

Correct. And the disassembler behavior should match that. Hence
in 32-/16-bit code VEX-encoded GPR instructions should not
disassemble with 64-bit register names, but with 32-bit ones. The
main aspect here is that for such instructions VEX.W is not
ignored in 64-bit mode, but is ignored in 32-/16-bit mode.
However, for VEX-encoded SIMD instructions, VEX.W sensitivity
is not bitness dependent. Hence we can't reasonably clear vex.w
in the VEX decoding code, as at that point we don't know the
main opcode byte yet. The code there, even before this patch,
chooses to reflect certain VEX bits into rex, and the patch here
simply fills some of the gaps left in that process.

May I suggest that you simply look at the testcase included with
the patch, and how each sub-block of it disassembles with a
non-patches disassembler?

Jan