Re: [PATCH v4 06/21] x86/fpu: Ignore APX when copying from/to guest FPU

[Dave Hansen]

On 5/14/26 09:04, Paolo Bonzini wrote:
...
>> Couldn't we, for instance, just let the APX registers use the "fpu"
>> ABIs? PKRU is weird too, but it still gets to use those ABIs.
> 
> For PKRU it makes sense because it is not kept in the FPU even for the
> non-guest case. This is not the case for EGPRs, but I guess it would
> be the same if the kernel was compiled with APX? If the kernel entry
> code would have to stash r16-r31 from userspace before entering C
> code, then we can add similar "unsigned long *egprs" arguments to
> copy_uabi_from_kernel_to_xstate, copy_uabi_to_xstate, and likewise in
> the other direction.

I think we're getting into the weeds a bit. Maybe we should focus on how
this affects the ABIs and work in from there. Like you mentioned, we
might or might not have kernel APX support and the ABI should make sense
no matter what we do inside the kernel.

The functions we're discussing for this patch are:

	fpu_copy_uabi_to_guest_fpstate()
	fpu_copy_guest_fpstate_to_uabi()

which implement the meat of the functionality of these IOCTLs:

	KVM_SET_XSAVE
	KVM_GET_XSAVE

So the question, visible to userspace, is whether the
KVM_{GET,SET}_XSAVE should APIs should be able to manage XFEATURE_APX
data or not. If we decide *not* to manage them there, there needs to be
a _separate_ ABI.

Are we on the same page so far?

If we _just_ look at making a good, consistent ABI, I don't think
XFEATURE_APX is special. The registers can be managed by XSAVE. There's
a KVM XSAVE ABI. Why would *this* feature be special from all of the others?

I don't think the fact that the kernel is using those registers as GPRs
changes what makes a good ABI. That's a kernel-internal implementation
detail.

Now, that's not to say we should ignore kernel complexity. Maybe making
a nice ABI is so nasty to the kernel internals that we shouldn't bother.
I _think_ that's what you're suggesting.

Is that right?