>>> On 27.09.16 at 15:28, <andrew.coop...@citrix.com> 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@lists.xen.org https://lists.xen.org/xen-devel
