[PATCH] x86/efi: Skip FPU save/restore for idle vCPU in EFI, runtime path

[Bernhard Kaindl <bernhardkaindl7@xxxxxxxxx>]

Hi Anthony, could you test this patch which exactly applies the changes Jan suggested? Summary:

Guard both EFI runtime FPU calls with !is_idle_vcpu() to skip save/restore

for idle vCPUs, which don't have an FPU context to save/restore,

much like the calls are guarded in __context_switch(),

where save/restore is done only for non-idle vCPUs.

As these simple guards should preferably go into Xen 4.22: Please test if there are any further regressions with the 'cmos-rtc-probe' workaround you just added removed to check if guarding the assertions as Jan suggested is enough to fix the issues triggered on your machine. Thanks, Bernhard The patch to test follows: [PATCH] x86/efi: Skip FPU save/restore for idle vCPU in EFI, runtime path

Anthony reported a boot-time crash in init_xen_time() via efi_get_time()

on a Broadwell-D system:

  Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195

The failing path is an EFI runtime call reached early during boot,

where current may still be the idle vCPU.

This became fragile after the lazy-FPU removal cleanup series.

In 1792bb9a99d2 ("x86: Cleanup cr0.TS flag handling"),

efi_rs_enter() was changed from save_fpu_enable() to vcpu_save_fpu(curr),

which unconditionally asserts !is_idle_vcpu(v)

so an EFI runtime call in idle context now asserts.

Likewise, in dba44e051209 ("x86: Remove fully_eager_fpu"),

efi_rs_leave() was changed to call vcpu_restore_fpu(curr),

which has the same assertion and can fail for the same reason.

Guard both EFI runtime FPU calls with !is_idle_vcpu() to skip save/restore

for idle vCPUs, which don't have an FPU context to save/restore,

much like the calls are guarded in __context_switch(),

where save/restore is done only for non-idle vCPUs.

Fixes: 1792bb9a99d2 ("x86: Cleanup cr0.TS flag handling")

Fixes: dba44e051209 ("x86: Remove fully_eager_fpu")

Reported-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>

Suggested-by: Jan Beulich <jbeulich@xxxxxxxx>

Signed-off-by: Bernhard Kaindl <bernhard.kaindl@xxxxxxxxxx>

---

 xen/common/efi/runtime.c | 6 ++++--

 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c

index a23fa75e37..596f2710fb 100644

--- a/xen/common/efi/runtime.c

+++ b/xen/common/efi/runtime.c

@@ -98,7 +98,8 @@ struct efi_rs_state efi_rs_enter(void)

      */

     sync_local_execstate();

     state.cr3 = read_cr3();

-    vcpu_save_fpu(current);

+    if ( !is_idle_vcpu(current) )

+        vcpu_save_fpu(current);

     asm volatile ( "fnclex; fldcw %0" :: "m" (fcw) );

     asm volatile ( "ldmxcsr %0" :: "m" (mxcsr) );

 

@@ -159,7 +160,8 @@ void efi_rs_leave(struct efi_rs_state *state)

     }

     irq_exit();

     spin_unlock(&efi_rs_lock);

-    vcpu_restore_fpu(curr);

+    if ( !is_idle_vcpu(curr) )

+        vcpu_restore_fpu(curr);

 }

 

 unsigned long efi_get_time(void)

--

2.43.0

--- PS: The suggestion by Jan to fix this issue: On 12/06/2026 16:17, Jan Beulich wrote:

> The thinko looks to be in 4b9851c64522 ("x86: Remove fpu_initialised/fpu_dirty"):
> While vcpu_restore_fpu() indeed unconditionally set the two boolean fields to
> true at that point, idle vCPU-s may never make it through that function, and
> hence ->fpu_dirtied would have remained false, triggering the (original) early
> exit from _vcpu_save_fpu(). Perhaps all we can do now is guard the call to
> vcpu_save_fpu() (and also the one to vcpu_restore_fpu() out of efi_rs_leave())
> by explicit is_idle_vcpu() checks. Much like the calls are guarded in
> __context_switch().
>
> Jan
>