[PATCH 1/2] x86: PadLock adjustments

[Mayshao-oc]

> On 26.11.2025 09:24, Mayshao-oc wrote:
> >> On 26.09.2025 14:57, Jan Beulich wrote:
> >>> For one, all PadLock insns depend on CR4.FXSR to be enabled, which 
> >>> means they ought to be taking FXSR as a prereq.
> > Sorry for the late reply. AFAIK CR4.FXSR indicates whether the OS 
> > supports the FXSAVE and FXRSTOR instructions, PadLock insns don't depend on it.
> 
> Quoting from "VIA PadLock Programming Guide", under "Enabling PadLock":
> 
> "3. SSE instructions must be enabled via the standard x86 method of enabling  the FXSAVE/FXRSTOR instructions using CR4[9] This enables the full set of  SSE instructions. If CR4[9] is not set, PadLock behaves as if it were  disabled via the MSR, regardless of the setting of the enable bits MSRs."
Thanks for your information, I got it.
> 
> >>> Furthermore none of them permits a REPNE prefix; such forms are 
> >>> documented to cause #UD. (This is mainly relevant for XSTORE, which 
> >>> doesn't include a REP prefix in its base encoding. For the others 
> >>> this merely is a change in what diagnostic is issued.)
> >>>
> >>> Finally it is documented that an operand size prefix also causes #UD.
> >>> ---
> >>> Question is whether for the GMI insns the data size prefix is 
> >>> invalid as well.
> >>
> >> Can you possibly answer this?
> > For the GMI insns the data size prefix is not a mandatory prefix like REPE/REPNE.
> > For example, the encoding of sm2 instruction is 0xf20fa6c0, 0x660fa6c0 
> > will cause #UD, but 0x66f20fa6c0 will not cause #UD.I think for the 
> > GMI insns, if only data size prefix present, it's invalid, if data 
> > size prefix present with REPE/REPNE, it's valid.
> 
> If additionally 0xf2660fa6c0 would also cause #UD, then that's pretty much in line with the use of these prefixes as operation-modifying ones (where undefined ones aren't simply ignored). If it doesn't already, we should try to have the disassembler cope with this.
I tested 0xf2660fa6c0, it would not cause #UD yet.
> 
> Jan
BR
Mayshao