[PATCH v1] x86: Support ZHAOXIN GMI instructions

[Jan Beulich]

On 14.10.2024 05:37, Jiang, Haochen wrote:
>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>> Sent: Monday, October 14, 2024 11:28 AM
>>
>> On 10/14/24 11:09, Jiang, Haochen wrote:
>>>
>>>
>>>
>>>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>>>> Sent: Monday, October 14, 2024 10:03 AM
>>>> To: binutils@sourceware.org
>>>>
>>>>          This patch adds support for Zhaoxin GMI instructions.
>>>>          The documentation is attached for your reference.
>>>>          Test ok, ok for trunk?
>>>
>>> The disassembler part looks extremely weird to me.
>>>
>>> I suppose the adding for this is not correct:
>>>
>>> @@ -1315,7 +1320,8 @@ enum
>>>   enum
>>>   {
>>>     THREE_BYTE_0F38 = 0,
>>> -  THREE_BYTE_0F3A
>>> +  THREE_BYTE_0F3A,
>>> +  THREE_BYTE_0FA6
>>>   };
>>>
>>> My understanding comes following, correct me if I am wrong.
>>>
>>> Let's take inst sm2 for example. The full encoding for sm2 is
>>> 0xf20fa6c0. In the encoding, a6 is opcode and c0 is modrm byte.
>>> This means a6 should be the "index", not a6c0 in your this part of
>>> patch:
>> All GMI instructions are three byte opcode, so for the inst sm2, c0 is not
>> modrm byte.
> 
> Maybe I did not make it clear here, the full opcode is f20fa6, where f2 is
> mandatory prefix and 0f is the escape opcode byte. These three bytes
> consist of the full opcode.
> 
> This will make c0 as modrm byte.

I agree - even if the byte isn't used as a ModR/M one, its decoding should
treat it so. That's no different from SFENCE, LFENCE, and MFENCE, to name
just a few. Plus - even the original PadLock insns match that pattern.
Nothing good will come from things being done differently here.

Jan