RE: [PATCH][v6] Support Intel USER_MSR

["Jiang, Haochen" <haochen.jiang@intel.com>]

> On 15.11.2023 04:34, Jiang, Haochen wrote:
> >>>> +
> >>>> +// USER_MSR instructions.
> >>>> +
> >>>> +urdmsr, 0xf20f38f8, USER_MSR|x64, RegMem|NoSuf|NoRex64,
> >> { Reg64,
> >>>> +Reg64 } urdmsr, 0xf2f8/0, USER_MSR|x64,
> >>>> +Modrm|Vex128|VexMap7|VexW0|NoSuf, { Imm32, Reg64 } uwrmsr,
> >>>> +0xf30f38f8, USER_MSR|x64, Modrm|NoSuf|NoRex64, { Reg64,
> Reg64 }
> >>>> +uwrmsr, 0xf3f8/0, USER_MSR|x64,
> Modrm|Vex128|VexMap7|VexW0|NoSuf,
> >>> {
> >>>> +Reg64, Imm32 }
> >>>
> >>> Actually I think the choice of Reg64 here for the operand specifying the
> MSR
> >>> index is misleading, even if in line with what the doc presently says in the
> >>> Opcode / Instruction column. For both insns the description says that only
> the
> >>> low 32 bits are used (and the Exceptions section confirms this). Such
> operands,
> >>> however, are expressed as Reg32 everywhere else. I'd like to suggest that
> the
> >>> spec be adjusted, and I'm heavily inclined to change binutils regardless.
> Thoughts?
> >
> > I suppose the reason why it is using Reg64 is because when the other
> operand is
> > register, it is rare not to align the register size. I checked SDE and ISE and only
> > got one case. And this reg size is inherited from that.
> 
> Only one? I know of two (MOVSX and MOVZX) without even needing to go
> look.

Oops, missing that due to the search string. There could be more.

> Both registers matching in size is sensible only if both also express the
> same kind of entity. (Moves between GPRs and MM/XMM registers are other
> examples, just that there it's also register "kind" that's different.)

That is the point we need to sync with our internal team.

Thx,
Haochen

> 
> Jan