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

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

On Tue, Sep 27, 2016 at 02:26:00AM -0600, Jan Beulich wrote:
> >>> 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.

Hi Jan:

My interpretation of the footnote comes from discussions with key people.
This is their understanding of the footnote.

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

Thanks for the reminder of xsetbv, xgetbv, xend, xtest.  I finally located their
opcode pages in Vol 2 5.2.  The descriptions of these opcodes disallows for
"pfx", which is consistent with the footnote.

Finally found the vmfunc opcode page in Vol 3 30.3, VMX Instruction Reference.
Agreed, there's no mention of prefixes, "pfx", on this page.  It appears
that the other VMX instructions in this section don't mention prefixes either.
Looking at Table A-6 "Opcode Extensions for One- and Two-Byte Opcodes":
vmcall, vmlaunch, vmresume, and vmxoff would need similar updating.

I can ask for updating of the VMX instuctions to include mention of prefixes.
Anything else as I gather requirements?

-Paul

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