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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/09/16 14:10, Jan Beulich wrote:
> This way we can at least size (and e.g. skip) them if needed, and we
> also won't raise the wrong fault due to not having read all relevant
> bytes.

What faults are you referring to?  #UD vs #GP from hitting the %cs limit?

>
> This at once adds correct raising of #UD for the three "ud<n>" flavors
> (Intel names only "ud2", but AMD names all three of them in their
> opcode maps), as that may make a difference to callers compared to
> getting back X86EMUL_UNHANDLEABLE.

Definitely a good improvement.  I have been meaning to do this for a while.

Intel does references 0FB9 in a footnote in the opcode map, but I can't
see any mention of 0FFF at all.

>
> Note on opcodes 0FA6 and 0FA7: These are VIA's PadLock instructions,
> which have a ModRM like byte where only register forms are valid. I.e.
> we could also use SrcImmByte there, but ModRM is more likely to be
> correct for a hypothetical extension allowing non-register operations.

Won't the use of ModRM possibly cause us to read too much if it end up
with SIB and displacement encoding?  OTOH, do we really care?

>
> Note on opcode 0FB8: I think we're safe to ignore JMPE (which doesn't
> take a ModRM byte, but an immediate).

It took a while to find out what this instruction is.  Mind indicating
that it is Itanium-specific in the commit message?

POPCNT, the aliased instruction takes a full ModRM byte with no space to
distinguish.

~Andrew

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