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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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/
cmpxchg).

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

Sure.

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

Jan


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