[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.