Re: [PATCH 1/2] x86: insn decoder: create artificial 3rd byte for 2-byte VEX

[Denys Vlasenko]

On 05/17/2014 05:59 PM, Masami Hiramatsu wrote:
> (2014/05/17 3:34), Denys Vlasenko wrote:
>> Before this patch, users need to do this to fetch vex.vvvv:
>>
>>         if (insn->vex_prefix.nbytes == 2) {
>>                 vex_vvvv = ((insn->vex_prefix.bytes[1] >> 3) & 0xf) ^ 0xf;
>>         }
>>         if (insn->vex_prefix.nbytes == 3) {
>>                 vex_vvvv = ((insn->vex_prefix.bytes[2] >> 3) & 0xf) ^ 0xf;
>>         }
>>
>> Make it so that insn->vex_prefix.bytes[2] always contains vex.wvvvvLpp bits.
> 
> I like this hack :)
> If you don't mind, please add inline functions to get such vex bits from
> struct insn too?

I prefer to add such functionality when the first user surfaces:
the needs of the user often dictate more suitable API.

In this case (VEX insns), the API isn't that straightforward.
For example, uprobe code narrowly escaped the need to detect maskmovq__
(0f f7) and maskmovdqu (66 0f f7 or equivalent VEX) instructions.

Let's assume we do need to detect them.
Merely fetching and looking at vex.mmmmm, vex.pp and opcode doesn't
really help that much in detecting these instructions:
with such simplistic help, user needs to check both VEX and legacy forms.

Perhaps a better API would be to form a word-sized "expanded opcode"
for vector and VEX insns. Something along the lines of:

[x.mmmmm.pp.opcode__]

where x bit indicates XOP insn (as opposed to VEX), pp indicate
none/66/F2/F3 prefixes, opcode__ is 8-bit opcode.
then checking for maskmovFOO insns would be easier.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/