[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/efi: Skip FPU save/restore for idle vCPU in EFI, runtime path
On 6/12/26 5:41 PM, Bernhard Kaindl wrote:
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>
---
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
Thanks.
~ Oleksii
|