[PATCH 8/8] Support APX JMPABS

[Hu, Lin1]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, November 27, 2023 6:32 PM
> To: Hu, Lin1 <lin1.hu@intel.com>
> Cc: Lu, Hongjiu <hongjiu.lu@intel.com>; ccoutant@gmail.com;
> binutils@sourceware.org; Cui, Lili <lili.cui@intel.com>
> Subject: Re: [PATCH 8/8] Support APX JMPABS
> 
> On 27.11.2023 10:03, Hu, Lin1 wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Monday, November 27, 2023 4:55 PM
> >>
> >> On 27.11.2023 09:46, Hu, Lin1 wrote:
> >>> If I use "{evex} vaddpd ymm0, ymm1, ymm2". If it's for register
> >>> considerations,
> >> I think bit 5, 6, 7 can all be zero. Because the insn doesn't use
> >> k0-k7 and the upper 256 bits of the registers ZMM0-ZMM15.
> >>
> >> How that? It clears the upper 256 bits of the destination register.
> >
> > OK, so bit 5 and 7 are not affected, it they are zero, I  think the exception
> shouldn't be triggered.
> 
> Except that the spec mandates that the three bits are all set or all clear.
> This could have been less strict, but that's too late now. For APX otoh it's not too
> late yet to avoid quirky behavior.
> 

We had a discussion with the people involved. XCR0.APX controls if enable the REX2 and Extended EVEX prefixes in CPU now. So JMPABS is affected by this bit.

New fields in XCR0:
	– APX_F – Intel® APX state and prefixes are governed by XCR0[APX_F=19]. This control bit
	enables Intel® APX ISA by enabling the use of the REX2 and Extended EVEX prefixes in IA-32e
	64-bit mode and by enabling the XSAVE feature set to manage Intel® APX state. Note that in
	64-bit mode, none of the Intel® APX features (including the REX2 and Extended EVEX prefixes
	and all new Intel® APX instructions) can be used until they are XCR0-enabled.

BRs,
Lin