[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 14.09.16 at 16:22, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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?

Or #PF.

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

Check AMD's.

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

That's why I've added that paragraph: I'd be fine either way, but I
do think the intention is a ModRM byte. Which is then also in line with
these opcodes' uses in early 386 and 486 processors (xbts/ibts/

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

Well, distinguishing them is possible in principle, as by the time we
process bytes past the main opcode one we already know whether
an F3 prefix was present. I simply think it's not worth trying to do


Xen-devel mailing list



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