Re: [PATCH 1/4] x86/fpu: Clear XSTATE_BV[i] in save state whenever XFD[i]=1

[Paolo Bonzini]

On 1/15/26 16:54, Dave Hansen wrote:
> On 1/1/26 01:05, Paolo Bonzini wrote:
> > When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in
> > response to a guest WRMSR, clear XFD-disabled features in the saved (or to
> > be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for
> > features that are disabled via the guest's XFD.  Because the kernel
> > executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1
> > will cause XRSTOR to #NM and panic the kernel.
>
> It would be really nice to see the actual ordering of events here. What
> order do the KVM_SET_XSAVE, XFD[$FOO]=1 and kernel_fpu_begin() have to
> happen in to trigger this?

The problematic case is described a couple paragraphs below: "This can 
happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and 
a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's 
call to fpu_update_guest_xfd()."

Or more in detail:

  Guest running with MSR_IA32_XFD = 0
    WRMSR(MSR_IA32_XFD)
    vmexit
  Host:
    enable IRQ
    interrupt handler
      kernel_fpu_begin() -> sets TIF_NEED_FPU_LOAD
        XSAVE -> stores XINUSE[18] = 1
        ...
      kernel_fpu_end()
    handle vmexit
      fpu_update_guest_xfd() -> XFD[18] = 1
    reenter guest
      fpu_swap_kvm_fpstate()
        XRSTOR -> XINUSE[18] = 1 && XFD[18] = 1 -> #NM and boom

With the patch, fpu_update_guest_xfd() sees TIF_NEED_FPU_LOAD set and 
clears the bit from xinuse.

Paolo