Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.16 at 20:13, <paul.c.lai@xxxxxxxxx> wrote:
> On Wed, Sep 21, 2016 at 10:22:32AM -0700, Lai, Paul wrote:
>> On Wed, Sep 21, 2016 at 02:39:58AM -0600, Jan Beulich wrote:
>> > >>> On 21.09.16 at 00:35, <paul.c.lai@xxxxxxxxx> wrote:
>> > > On Tue, Sep 20, 2016 at 09:50:15AM -0600, Jan Beulich wrote:
>> > >> 
>> > >> Paul, there's been no reply to
>> > >> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00380.html
>> > >>  
>> > > 
>> > > The refered to patch, commit a1b1572833, adds a check for vmfunc.
>> > > I look a little time to look at the SDM and finally found the reference.
>> > > The vmfunc can be found in Table A-6 "Opcode Extensions for One- and Two-
>> > > byte Opcodes by Group Number" on page A-18 Vol. 2D of the
>> > >  e64-ia-32-architectures-software-developer-manual-325462.pdf.
>> > > The values for vmfunc match the values in the code.
>> > > I also took the liberty of looking at the other existing cases in the
>> > > switch statement, and can find RDTSCP and INVLPG. The CLZERO extension
>> > > value is a mystery to me.
>> > 
>> > Well - the question raised was whether the documentation is
>> > perhaps wrong.
>> 
>> VMFUNC allowing 66, F2, and F3 prefixes when
>> > other opcodes in its neighborhood (e.g. xsetbv, xtest, xend)
>> > don't seems at least suspicious. 
>> 
>> Thanks for the clearer problem statement. 
>> 
>> > Extensions originating from AMD
>> > (rdtscp, clzero) can't be reasonably taken for reference.
>> > 
>> > Jan
>> > 
>> 
>> I'll check....
>> 
> At the bottom of the A-6 Table ("Opcode Extensions for One- and Two- byte
> Opcodes by Group Number") there's a footnote that states
>    All blanks in all opcode maps are reserved and must not be used.
>    Do not depend on the operation of undefined or reserved locations
> So, since the "pfx" value for Group 7 opcodes are "blank", none are allowed,
> and an "#UD" is expected if a "pfx" is used.

This foot note can't possibly apply to the pfx column: Blank entries
there mean at best "no prefix", but certainly not "reserved". Plus
most opcodes allow namely the 66 prefix (as operand size override),
and I'm also sure the F2 and F3 prefixes get ignored for many of
the table entries.

> I also checked the narrative descriptions of vmfunc (and similar opcodes,
> in particular the list in 25.1.3 "Instructions That Cause VM Exits
> Conditionally").  None of the descriptions seem to state explicitly the
> expected values of "pfx", nor the behavior of a "bad pfx".  That said, the
> table and footnote seem to be the most explicit, cleanest way of 
> communicating the information.

As mentioned elsewhere, the examples of other instructions (xsetbv,
xgetbv, xend, xtest) were given because their instruction pages all
mention 66, F2, and F3 as invalid, and they're all in the same group 7
(and all in the same table column). enclu (documented in vol 3) btw
also lists these prefixes as invalid.

Jan


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