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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Feb 24, 2017 at 12:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> 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
>

Please send your patch as attachment since I can't apply it.


-- 
H.J.