Re: [Patch] x86emul: simplify prefix handling for VMFUNC

["Lai, Paul" <paul.c.lai@intel.com>]

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@intel.com> 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.

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.

-Paul


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