On Thu, Sep 24, 2026 at 5:17 PM Richard Henderson
<[email protected]> wrote:
>
> On 9/23/26 10:30, Paolo Bonzini wrote:
> > + case X86_EVEX_APX:
> > + case X86_EVEX_APX_cmp:
> > + case X86_EVEX_APX_pp2:
> > + case X86_EVEX_APX_zu:
> > + /* Only reached through EVEX map 4. */
> > + assert(!(s->prefix & PREFIX_VEX));
> > + if (s->vex_l) {
> > + goto illegal;
> > + }
> > + if ((s->prefix & PREFIX_EVEX) && !validate_evex_apx(s, decode)) {
> > + return false;
> > + }
>
> They're only reached by map4, so surely
>
> assert(s->prefix & PREFIX_EVEX);
>
> is more appropriate, and the subsequent test for evex moot.
No, validate_vex() is also invoked for non-VEX/EVEX instructions. In
that case, for example, it will raise #UD for opcodes that are only
the VEX/EVEX maps and not in the 0F map. See for example:
case 13:
if (!(s->prefix & (PREFIX_VEX | PREFIX_EVEX))) {
goto illegal;
}
which will reject an ANDN that is encoded as 0F 38 F2 instead of using VEX/EVEX.
For this patch, in particular, group1, group2, group3 and group4_5 are
shared between the root map and EVEX map 4. Some of the instructions
starting with F6/F7/FE/FF will call validate_vpx even with no prefix
and have to be accepted. I'll add a comment
/* Not reached through any VEX map. */
for clarity.
Paolo
