Re: [Xen-devel] [PATCH 04/17] x86emul: complete decoding of two-byte instructions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.09.16 at 15:28, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 26/09/16 08:34, Jan Beulich wrote:
>>
>>> 0F6F was previously ImplicitOps|ModRM, but looks like it should be ModRM 
>>> like the rest of 0F6x.  0F7F, 0FC7 and 0FE7 similarly.
>> Why? As mentioned elsewhere I think the (otherwise benign)
>> ImplicitOps (as well as the individual DstImplicit and SrcImplicit)
>> serve as documentation: Opcodes we actually handle have them
>> specified, whereas opcodes getting decoded but not emulated
>> don't. See the MOVQ and MOVD patches in the other series, which
>> add ImplicitOps to the table entries they add emulation for.
> 
> By that argument, any instruction we have an emulation for should gain
> ImplicitOps.

Unless it has Src* or Dst* specifiers, yes. And I believe that to be
the case.

> As it has the value 0, I only find that it further confuses an already
> complicated piece of logic, as reading the decode gives the false
> impression that something is different.

Well, I wouldn't necessarily mind cleaning this up (albeit I'm also not
fully convinced, as I think this doc aspect has some relevance), but
not in this series.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel