Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Anthony PERARD]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Hi,

Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
netbooted and EFI.

Xen call trace:
   [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
   [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
   [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
   [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
   [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
   [<ffff82d0402043e7>] F __high_start+0xb7/0xc0

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

A few more lines from Xen:
    CPU Vendor: Intel, Family 6 (0x6), Model 86 (0x56), Stepping 3 (raw 00050663)
    Bootloader: GRUB 2.06
    [...]
    Enabling APIC mode.  Using 2 I/O APICs
    ENABLING IO-APIC IRQs
     -> Using old ACK method
     ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
    TSC deadline timer enabled
    Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195

Commit this Xen is built from: 50936ea05660.

full logs at:
    https://paste.vates.tech/?bd8a9a0955798a97#A1DU2efwUt7bbHQUxdo9UXGcsJ2XPNJNZHPz87LqLtcF

Thanks,


--
 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Fri, Jun 12, 2026 at 03:53:49PM +0200, Anthony PERARD wrote:
> Hi,
> 
> Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
> a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
> netbooted and EFI.
> 
> Xen call trace:
>    [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
>    [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
>    [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
>    [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
>    [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
>    [<ffff82d0402043e7>] F __high_start+0xb7/0xc0
> 
> Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
> 
> A few more lines from Xen:
>     CPU Vendor: Intel, Family 6 (0x6), Model 86 (0x56), Stepping 3 (raw 00050663)
>     Bootloader: GRUB 2.06
>     [...]
>     Enabling APIC mode.  Using 2 I/O APICs
>     ENABLING IO-APIC IRQs
>      -> Using old ACK method
>      ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>     TSC deadline timer enabled
>     Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
> 
> Commit this Xen is built from: 50936ea05660.

Interesting, the efi_get_time() way is nowadays a fallback if cmos one
isn't advertised. Can you try adding `cmos-rtc-probe`?

Anyway, surely it shouldn't crash... The commit you mentioned has "No
functional change intended", but well...

> full logs at:
>     https://paste.vates.tech/?bd8a9a0955798a97#A1DU2efwUt7bbHQUxdo9UXGcsJ2XPNJNZHPz87LqLtcF

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Andrew Cooper]

On 12/06/2026 3:11 pm, Marek Marczykowski-Górecki wrote:
> On Fri, Jun 12, 2026 at 03:53:49PM +0200, Anthony PERARD wrote:
>> Hi,
>>
>> Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
>> a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
>> netbooted and EFI.
>>
>> Xen call trace:
>>    [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
>>    [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
>>    [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
>>    [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
>>    [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
>>    [<ffff82d0402043e7>] F __high_start+0xb7/0xc0
>>
>> Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>
>> A few more lines from Xen:
>>     CPU Vendor: Intel, Family 6 (0x6), Model 86 (0x56), Stepping 3 (raw 00050663)
>>     Bootloader: GRUB 2.06
>>     [...]
>>     Enabling APIC mode.  Using 2 I/O APICs
>>     ENABLING IO-APIC IRQs
>>      -> Using old ACK method
>>      ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>>     TSC deadline timer enabled
>>     Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>
>> Commit this Xen is built from: 50936ea05660.
> Interesting, the efi_get_time() way is nowadays a fallback if cmos one
> isn't advertised. Can you try adding `cmos-rtc-probe`?
>
> Anyway, surely it shouldn't crash... The commit you mentioned has "No
> functional change intended", but well...

Well, no intended change.  It was a very big patch.

Nothing should ever be using efi_get_time().  It's unusable (i.e.
crashing) on hundreds of millions of machines.

So, while we obviously do need to fix the assertion, this is "only"
collateral damage from having fallen into the efi_get_time() path in the
first place.  That wants investigating too.

~Andrew

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Jan Beulich]

On 12.06.2026 16:18, Andrew Cooper wrote:
> On 12/06/2026 3:11 pm, Marek Marczykowski-Górecki wrote:
>> On Fri, Jun 12, 2026 at 03:53:49PM +0200, Anthony PERARD wrote:
>>> Hi,
>>>
>>> Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
>>> a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
>>> netbooted and EFI.
>>>
>>> Xen call trace:
>>>    [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
>>>    [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
>>>    [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
>>>    [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
>>>    [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
>>>    [<ffff82d0402043e7>] F __high_start+0xb7/0xc0
>>>
>>> Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>>
>>> A few more lines from Xen:
>>>     CPU Vendor: Intel, Family 6 (0x6), Model 86 (0x56), Stepping 3 (raw 00050663)
>>>     Bootloader: GRUB 2.06
>>>     [...]
>>>     Enabling APIC mode.  Using 2 I/O APICs
>>>     ENABLING IO-APIC IRQs
>>>      -> Using old ACK method
>>>      ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>>>     TSC deadline timer enabled
>>>     Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>>
>>> Commit this Xen is built from: 50936ea05660.
>> Interesting, the efi_get_time() way is nowadays a fallback if cmos one
>> isn't advertised. Can you try adding `cmos-rtc-probe`?
>>
>> Anyway, surely it shouldn't crash... The commit you mentioned has "No
>> functional change intended", but well...
> 
> Well, no intended change.  It was a very big patch.
> 
> Nothing should ever be using efi_get_time().  It's unusable (i.e.
> crashing) on hundreds of millions of machines.
> 
> So, while we obviously do need to fix the assertion, this is "only"
> collateral damage from having fallen into the efi_get_time() path in the
> first place.  That wants investigating too.

Perhaps a reduced-hardware system with ACPI_FADT_NO_CMOS_RTC set? On such
systems efi_get_time() would better work properly.

Jan

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Andrew Cooper]

On 12/06/2026 3:20 pm, Jan Beulich wrote:
> On 12.06.2026 16:18, Andrew Cooper wrote:
>> On 12/06/2026 3:11 pm, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jun 12, 2026 at 03:53:49PM +0200, Anthony PERARD wrote:
>>>> Hi,
>>>>
>>>> Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
>>>> a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
>>>> netbooted and EFI.
>>>>
>>>> Xen call trace:
>>>>    [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
>>>>    [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
>>>>    [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
>>>>    [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
>>>>    [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
>>>>    [<ffff82d0402043e7>] F __high_start+0xb7/0xc0
>>>>
>>>> Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>>>
>>>> A few more lines from Xen:
>>>>     CPU Vendor: Intel, Family 6 (0x6), Model 86 (0x56), Stepping 3 (raw 00050663)
>>>>     Bootloader: GRUB 2.06
>>>>     [...]
>>>>     Enabling APIC mode.  Using 2 I/O APICs
>>>>     ENABLING IO-APIC IRQs
>>>>      -> Using old ACK method
>>>>      ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>>>>     TSC deadline timer enabled
>>>>     Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>>>
>>>> Commit this Xen is built from: 50936ea05660.
>>> Interesting, the efi_get_time() way is nowadays a fallback if cmos one
>>> isn't advertised. Can you try adding `cmos-rtc-probe`?
>>>
>>> Anyway, surely it shouldn't crash... The commit you mentioned has "No
>>> functional change intended", but well...
>> Well, no intended change.  It was a very big patch.
>>
>> Nothing should ever be using efi_get_time().  It's unusable (i.e.
>> crashing) on hundreds of millions of machines.
>>
>> So, while we obviously do need to fix the assertion, this is "only"
>> collateral damage from having fallen into the efi_get_time() path in the
>> first place.  That wants investigating too.
> Perhaps a reduced-hardware system with ACPI_FADT_NO_CMOS_RTC set?

The identified system is a Broadwell-D.

Come to think of it, there were some systems of that era which (falsely)
claimed to have no CMOS.  (An HP Haswell Blade comes to mind, but it
will be a similar chipset.)

> On such systems efi_get_time() would better work properly.

Wouldn't that have been nice.  On the bug I looked at at the time, it
was just as broken as prior systems.

It's a vicious positive feedback cycle.  Windows and Linux ignore
efi_get_time() entirely because it's broken in a way you can't probe
for, and as a result the codepath get 0 testing by OEMs/ISVs and nothing
gets fixed.

~Andrew

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Jan Beulich]

On 12.06.2026 16:32, Andrew Cooper wrote:
> On 12/06/2026 3:20 pm, Jan Beulich wrote:
>> On 12.06.2026 16:18, Andrew Cooper wrote:
>>> On 12/06/2026 3:11 pm, Marek Marczykowski-Górecki wrote:
>>>> On Fri, Jun 12, 2026 at 03:53:49PM +0200, Anthony PERARD wrote:
>>>>> Hi,
>>>>>
>>>>> Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
>>>>> a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
>>>>> netbooted and EFI.
>>>>>
>>>>> Xen call trace:
>>>>>    [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
>>>>>    [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
>>>>>    [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
>>>>>    [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
>>>>>    [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
>>>>>    [<ffff82d0402043e7>] F __high_start+0xb7/0xc0
>>>>>
>>>>> Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>>>>
>>>>> A few more lines from Xen:
>>>>>     CPU Vendor: Intel, Family 6 (0x6), Model 86 (0x56), Stepping 3 (raw 00050663)
>>>>>     Bootloader: GRUB 2.06
>>>>>     [...]
>>>>>     Enabling APIC mode.  Using 2 I/O APICs
>>>>>     ENABLING IO-APIC IRQs
>>>>>      -> Using old ACK method
>>>>>      ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>>>>>     TSC deadline timer enabled
>>>>>     Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>>>>
>>>>> Commit this Xen is built from: 50936ea05660.
>>>> Interesting, the efi_get_time() way is nowadays a fallback if cmos one
>>>> isn't advertised. Can you try adding `cmos-rtc-probe`?
>>>>
>>>> Anyway, surely it shouldn't crash... The commit you mentioned has "No
>>>> functional change intended", but well...
>>> Well, no intended change.  It was a very big patch.
>>>
>>> Nothing should ever be using efi_get_time().  It's unusable (i.e.
>>> crashing) on hundreds of millions of machines.
>>>
>>> So, while we obviously do need to fix the assertion, this is "only"
>>> collateral damage from having fallen into the efi_get_time() path in the
>>> first place.  That wants investigating too.
>> Perhaps a reduced-hardware system with ACPI_FADT_NO_CMOS_RTC set?
> 
> The identified system is a Broadwell-D.
> 
> Come to think of it, there were some systems of that era which (falsely)
> claimed to have no CMOS.  (An HP Haswell Blade comes to mind, but it
> will be a similar chipset.)
> 
>> On such systems efi_get_time() would better work properly.
> 
> Wouldn't that have been nice.  On the bug I looked at at the time, it
> was just as broken as prior systems.
> 
> It's a vicious positive feedback cycle.  Windows and Linux ignore
> efi_get_time() entirely because it's broken in a way you can't probe
> for, and as a result the codepath get 0 testing by OEMs/ISVs and nothing
> gets fixed.

Do Linux and Windows then ignore ACPI_FADT_NO_CMOS_RTC on such systems? Else
how would they establish wallclock time there?

Jan

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Andrew Cooper]

On 12/06/2026 3:45 pm, Jan Beulich wrote:
> On 12.06.2026 16:32, Andrew Cooper wrote:
>> On 12/06/2026 3:20 pm, Jan Beulich wrote:
>>> On 12.06.2026 16:18, Andrew Cooper wrote:
>>>> On 12/06/2026 3:11 pm, Marek Marczykowski-Górecki wrote:
>>>>> On Fri, Jun 12, 2026 at 03:53:49PM +0200, Anthony PERARD wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
>>>>>> a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
>>>>>> netbooted and EFI.
>>>>>>
>>>>>> Xen call trace:
>>>>>>    [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
>>>>>>    [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
>>>>>>    [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
>>>>>>    [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
>>>>>>    [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
>>>>>>    [<ffff82d0402043e7>] F __high_start+0xb7/0xc0
>>>>>>
>>>>>> Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>>>>>
>>>>>> A few more lines from Xen:
>>>>>>     CPU Vendor: Intel, Family 6 (0x6), Model 86 (0x56), Stepping 3 (raw 00050663)
>>>>>>     Bootloader: GRUB 2.06
>>>>>>     [...]
>>>>>>     Enabling APIC mode.  Using 2 I/O APICs
>>>>>>     ENABLING IO-APIC IRQs
>>>>>>      -> Using old ACK method
>>>>>>      ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
>>>>>>     TSC deadline timer enabled
>>>>>>     Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
>>>>>>
>>>>>> Commit this Xen is built from: 50936ea05660.
>>>>> Interesting, the efi_get_time() way is nowadays a fallback if cmos one
>>>>> isn't advertised. Can you try adding `cmos-rtc-probe`?
>>>>>
>>>>> Anyway, surely it shouldn't crash... The commit you mentioned has "No
>>>>> functional change intended", but well...
>>>> Well, no intended change.  It was a very big patch.
>>>>
>>>> Nothing should ever be using efi_get_time().  It's unusable (i.e.
>>>> crashing) on hundreds of millions of machines.
>>>>
>>>> So, while we obviously do need to fix the assertion, this is "only"
>>>> collateral damage from having fallen into the efi_get_time() path in the
>>>> first place.  That wants investigating too.
>>> Perhaps a reduced-hardware system with ACPI_FADT_NO_CMOS_RTC set?
>> The identified system is a Broadwell-D.
>>
>> Come to think of it, there were some systems of that era which (falsely)
>> claimed to have no CMOS.  (An HP Haswell Blade comes to mind, but it
>> will be a similar chipset.)
>>
>>> On such systems efi_get_time() would better work properly.
>> Wouldn't that have been nice.  On the bug I looked at at the time, it
>> was just as broken as prior systems.
>>
>> It's a vicious positive feedback cycle.  Windows and Linux ignore
>> efi_get_time() entirely because it's broken in a way you can't probe
>> for, and as a result the codepath get 0 testing by OEMs/ISVs and nothing
>> gets fixed.
> Do Linux and Windows then ignore ACPI_FADT_NO_CMOS_RTC on such systems? Else
> how would they establish wallclock time there?

I can't speak to windows, but the absence of a wallclock is not a
problem for Linux.

It shouldn't be for Xen either.  AIUI, we use the wallclock for two things:

* One of the boot timestamp modes
* vRTC->current_tm (only the internal baseline, which can be done with a
plain s_time_t instead)

Both have been tentatively agreed to be removed for MISRA reasons
(dropping gmtime() specifically), although there's been no real movement
here.

~Andrew

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Anthony PERARD]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On Fri, Jun 12, 2026 at 03:32:00PM +0100, Andrew Cooper wrote:
> On 12/06/2026 3:20 pm, Jan Beulich wrote:
> > On 12.06.2026 16:18, Andrew Cooper wrote:
> >> Well, no intended change.  It was a very big patch.
> >>
> >> Nothing should ever be using efi_get_time().  It's unusable (i.e.
> >> crashing) on hundreds of millions of machines.
> >>
> >> So, while we obviously do need to fix the assertion, this is "only"
> >> collateral damage from having fallen into the efi_get_time() path in the
> >> first place.  That wants investigating too.
> > Perhaps a reduced-hardware system with ACPI_FADT_NO_CMOS_RTC set?
> 
> The identified system is a Broadwell-D.
> 
> Come to think of it, there were some systems of that era which (falsely)
> claimed to have no CMOS.  (An HP Haswell Blade comes to mind, but it
> will be a similar chipset.)

Some info from the boot log about the machine:
    HPE ProLiant m510 Server Cartridge
    BIOS Version: H05 v1.98 (02/02/2023)
    System Memory: 32 GB
    1 Processor(s) detected, 8 total cores enabled, Hyperthreading is enabled
    Proc 1: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz
    HPE Power Profile Mode: Custom
    Power Regulator Mode: Dynamic Power Savings
    Advanced Memory Protection Mode: Advanced ECC Support
    Boot Mode: UEFI
    HPE SmartMemory authenticated in all populated DIMM slots.

One of the cartridge on a Moonshot.

> > On such systems efi_get_time() would better work properly.

I guess it works fine on this system. On a different cartridge, with a
Xen build prior to the commit, I have in the boot logs:

    Wallclock source: EFI


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Roger Pau Monné]

On Fri, Jun 12, 2026 at 05:17:31PM +0200, Anthony PERARD wrote:
> On Fri, Jun 12, 2026 at 03:32:00PM +0100, Andrew Cooper wrote:
> > On 12/06/2026 3:20 pm, Jan Beulich wrote:
> > > On 12.06.2026 16:18, Andrew Cooper wrote:
> > >> Well, no intended change.  It was a very big patch.
> > >>
> > >> Nothing should ever be using efi_get_time().  It's unusable (i.e.
> > >> crashing) on hundreds of millions of machines.
> > >>
> > >> So, while we obviously do need to fix the assertion, this is "only"
> > >> collateral damage from having fallen into the efi_get_time() path in the
> > >> first place.  That wants investigating too.
> > > Perhaps a reduced-hardware system with ACPI_FADT_NO_CMOS_RTC set?
> > 
> > The identified system is a Broadwell-D.
> > 
> > Come to think of it, there were some systems of that era which (falsely)
> > claimed to have no CMOS.  (An HP Haswell Blade comes to mind, but it
> > will be a similar chipset.)
> 
> Some info from the boot log about the machine:
>     HPE ProLiant m510 Server Cartridge
>     BIOS Version: H05 v1.98 (02/02/2023)
>     System Memory: 32 GB
>     1 Processor(s) detected, 8 total cores enabled, Hyperthreading is enabled
>     Proc 1: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz
>     HPE Power Profile Mode: Custom
>     Power Regulator Mode: Dynamic Power Savings
>     Advanced Memory Protection Mode: Advanced ECC Support
>     Boot Mode: UEFI
>     HPE SmartMemory authenticated in all populated DIMM slots.
> 
> One of the cartridge on a Moonshot.
> 
> > > On such systems efi_get_time() would better work properly.
> 
> I guess it works fine on this system. On a different cartridge, with a
> Xen build prior to the commit, I have in the boot logs:
> 
>     Wallclock source: EFI

Can you provide the decoded dump of the ACPI FADT table?

Thanks, Roger.

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Anthony PERARD]

[-- Attachment #1: Type: text/plain, Size: 12567 bytes --]

On Mon, Jun 15, 2026 at 11:02:05AM +0200, Roger Pau Monné wrote:
> On Fri, Jun 12, 2026 at 05:17:31PM +0200, Anthony PERARD wrote:
> > On Fri, Jun 12, 2026 at 03:32:00PM +0100, Andrew Cooper wrote:
> > > On 12/06/2026 3:20 pm, Jan Beulich wrote:
> > > > On 12.06.2026 16:18, Andrew Cooper wrote:
> > > >> Well, no intended change.  It was a very big patch.
> > > >>
> > > >> Nothing should ever be using efi_get_time().  It's unusable (i.e.
> > > >> crashing) on hundreds of millions of machines.
> > > >>
> > > >> So, while we obviously do need to fix the assertion, this is "only"
> > > >> collateral damage from having fallen into the efi_get_time() path in the
> > > >> first place.  That wants investigating too.
> > > > Perhaps a reduced-hardware system with ACPI_FADT_NO_CMOS_RTC set?
> > > 
> > > The identified system is a Broadwell-D.
> > > 
> > > Come to think of it, there were some systems of that era which (falsely)
> > > claimed to have no CMOS.  (An HP Haswell Blade comes to mind, but it
> > > will be a similar chipset.)
> > 
> > Some info from the boot log about the machine:
> >     HPE ProLiant m510 Server Cartridge
> >     BIOS Version: H05 v1.98 (02/02/2023)
> >     System Memory: 32 GB
> >     1 Processor(s) detected, 8 total cores enabled, Hyperthreading is enabled
> >     Proc 1: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz
> >     HPE Power Profile Mode: Custom
> >     Power Regulator Mode: Dynamic Power Savings
> >     Advanced Memory Protection Mode: Advanced ECC Support
> >     Boot Mode: UEFI
> >     HPE SmartMemory authenticated in all populated DIMM slots.
> > 
> > One of the cartridge on a Moonshot.
> > 
> > > > On such systems efi_get_time() would better work properly.
> > 
> > I guess it works fine on this system. On a different cartridge, with a
> > Xen build prior to the commit, I have in the boot logs:
> > 
> >     Wallclock source: EFI
> 
> Can you provide the decoded dump of the ACPI FADT table?

Sure, I hope it's the right one, it seems I needed to look for FACP
instead of FADT, here we go:

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20221020 (64-bit version)
 * Copyright (c) 2000 - 2022 Intel Corporation
 *
 * Disassembly of facp.dat, Mon Jun 15 14:29:25 2026
 *
 * ACPI Data Table [FACP]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue (in hex)
 */

[000h 0000 004h]                   Signature : "FACP"    [Fixed ACPI Description Table (FADT)]
[004h 0004 004h]                Table Length : 0000010C
[008h 0008 001h]                    Revision : 05
[009h 0009 001h]                    Checksum : ED
[00Ah 0010 006h]                      Oem ID : "HP    "
[010h 0016 008h]                Oem Table ID : "ProLiant"
[018h 0024 004h]                Oem Revision : 00000001
[01Ch 0028 004h]             Asl Compiler ID : "HP  "
[020h 0032 004h]       Asl Compiler Revision : 00000001

[024h 0036 004h]                FACS Address : 7B581000
[028h 0040 004h]                DSDT Address : 7B7E2000
[02Ch 0044 001h]                       Model : 00
[02Dh 0045 001h]                  PM Profile : 04 [Enterprise Server]
[02Eh 0046 002h]               SCI Interrupt : 0009
[030h 0048 004h]            SMI Command Port : 000000B2
[034h 0052 001h]           ACPI Enable Value : A0
[035h 0053 001h]          ACPI Disable Value : A1
[036h 0054 001h]              S4BIOS Command : 00
[037h 0055 001h]             P-State Control : 00
[038h 0056 004h]    PM1A Event Block Address : 00000400
[03Ch 0060 004h]    PM1B Event Block Address : 00000000
[040h 0064 004h]  PM1A Control Block Address : 00000404
[044h 0068 004h]  PM1B Control Block Address : 00000000
[048h 0072 004h]   PM2 Control Block Address : 00000450
[04Ch 0076 004h]      PM Timer Block Address : 00000408
[050h 0080 004h]          GPE0 Block Address : 00000420
[054h 0084 004h]          GPE1 Block Address : 00000000
[058h 0088 001h]      PM1 Event Block Length : 04
[059h 0089 001h]    PM1 Control Block Length : 02
[05Ah 0090 001h]    PM2 Control Block Length : 01
[05Bh 0091 001h]       PM Timer Block Length : 04
[05Ch 0092 001h]           GPE0 Block Length : 10
[05Dh 0093 001h]           GPE1 Block Length : 00
[05Eh 0094 001h]            GPE1 Base Offset : 00
[05Fh 0095 001h]                _CST Support : 00
[060h 0096 002h]                  C2 Latency : 0065
[062h 0098 002h]                  C3 Latency : 03E9
[064h 0100 002h]              CPU Cache Size : 0000
[066h 0102 002h]          Cache Flush Stride : 0000
[068h 0104 001h]           Duty Cycle Offset : 01
[069h 0105 001h]            Duty Cycle Width : 00
[06Ah 0106 001h]         RTC Day Alarm Index : 0D
[06Bh 0107 001h]       RTC Month Alarm Index : 00
[06Ch 0108 001h]           RTC Century Index : 32
[06Dh 0109 002h]  Boot Flags (decoded below) : 0033
               Legacy Devices Supported (V2) : 1
            8042 Present on ports 60/64 (V2) : 1
                        VGA Not Present (V4) : 0
                      MSI Not Supported (V4) : 0
                PCIe ASPM Not Supported (V4) : 1
                   CMOS RTC Not Present (V5) : 1
[06Fh 0111 001h]                    Reserved : 00
[070h 0112 004h]       Flags (decoded below) : 000004A5
      WBINVD instruction is operational (V1) : 1
              WBINVD flushes all caches (V1) : 0
                    All CPUs support C1 (V1) : 1
                  C2 works on MP system (V1) : 0
            Control Method Power Button (V1) : 0
            Control Method Sleep Button (V1) : 1
        RTC wake not in fixed reg space (V1) : 0
            RTC can wake system from S4 (V1) : 1
                        32-bit PM Timer (V1) : 0
                      Docking Supported (V1) : 0
               Reset Register Supported (V2) : 1
                            Sealed Case (V3) : 0
                    Headless - No Video (V3) : 0
        Use native instr after SLP_TYPx (V3) : 0
              PCIEXP_WAK Bits Supported (V4) : 0
                     Use Platform Timer (V4) : 0
               RTC_STS valid on S4 wake (V4) : 0
                Remote Power-on capable (V4) : 0
                 Use APIC Cluster Model (V4) : 0
     Use APIC Physical Destination Mode (V4) : 0
                       Hardware Reduced (V5) : 0
                      Low Power S0 Idle (V5) : 0

[074h 0116 00Ch]              Reset Register : [Generic Address Structure]
[074h 0116 001h]                    Space ID : 01 [SystemIO]
[075h 0117 001h]                   Bit Width : 08
[076h 0118 001h]                  Bit Offset : 00
[077h 0119 001h]        Encoded Access Width : 01 [Byte Access:8]
[078h 0120 008h]                     Address : 0000000000000CF9

[080h 0128 001h]        Value to cause reset : 06
[081h 0129 002h]   ARM Flags (decoded below) : 0000
                              PSCI Compliant : 0
                       Must use HVC for PSCI : 0

[083h 0131 001h]         FADT Minor Revision : 00
[084h 0132 008h]                FACS Address : 0000000000000000
[08Ch 0140 008h]                DSDT Address : 000000007B7E2000
[094h 0148 00Ch]            PM1A Event Block : [Generic Address Structure]
[094h 0148 001h]                    Space ID : 01 [SystemIO]
[095h 0149 001h]                   Bit Width : 20
[096h 0150 001h]                  Bit Offset : 00
[097h 0151 001h]        Encoded Access Width : 02 [Word Access:16]
[098h 0152 008h]                     Address : 0000000000000400

[0A0h 0160 00Ch]            PM1B Event Block : [Generic Address Structure]
[0A0h 0160 001h]                    Space ID : 01 [SystemIO]
[0A1h 0161 001h]                   Bit Width : 00
[0A2h 0162 001h]                  Bit Offset : 00
[0A3h 0163 001h]        Encoded Access Width : 00 [Undefined/Legacy]
[0A4h 0164 008h]                     Address : 0000000000000000

[0ACh 0172 00Ch]          PM1A Control Block : [Generic Address Structure]
[0ACh 0172 001h]                    Space ID : 01 [SystemIO]
[0ADh 0173 001h]                   Bit Width : 10
[0AEh 0174 001h]                  Bit Offset : 00
[0AFh 0175 001h]        Encoded Access Width : 02 [Word Access:16]
[0B0h 0176 008h]                     Address : 0000000000000404

[0B8h 0184 00Ch]          PM1B Control Block : [Generic Address Structure]
[0B8h 0184 001h]                    Space ID : 01 [SystemIO]
[0B9h 0185 001h]                   Bit Width : 00
[0BAh 0186 001h]                  Bit Offset : 00
[0BBh 0187 001h]        Encoded Access Width : 00 [Undefined/Legacy]
[0BCh 0188 008h]                     Address : 0000000000000000

[0C4h 0196 00Ch]           PM2 Control Block : [Generic Address Structure]
[0C4h 0196 001h]                    Space ID : 01 [SystemIO]
[0C5h 0197 001h]                   Bit Width : 08
[0C6h 0198 001h]                  Bit Offset : 00
[0C7h 0199 001h]        Encoded Access Width : 00 [Undefined/Legacy]
[0C8h 0200 008h]                     Address : 0000000000000450

[0D0h 0208 00Ch]              PM Timer Block : [Generic Address Structure]
[0D0h 0208 001h]                    Space ID : 01 [SystemIO]
[0D1h 0209 001h]                   Bit Width : 20
[0D2h 0210 001h]                  Bit Offset : 00
[0D3h 0211 001h]        Encoded Access Width : 03 [DWord Access:32]
[0D4h 0212 008h]                     Address : 0000000000000408

[0DCh 0220 00Ch]                  GPE0 Block : [Generic Address Structure]
[0DCh 0220 001h]                    Space ID : 01 [SystemIO]
[0DDh 0221 001h]                   Bit Width : 80
[0DEh 0222 001h]                  Bit Offset : 00
[0DFh 0223 001h]        Encoded Access Width : 01 [Byte Access:8]
[0E0h 0224 008h]                     Address : 0000000000000420

[0E8h 0232 00Ch]                  GPE1 Block : [Generic Address Structure]
[0E8h 0232 001h]                    Space ID : 01 [SystemIO]
[0E9h 0233 001h]                   Bit Width : 00
[0EAh 0234 001h]                  Bit Offset : 00
[0EBh 0235 001h]        Encoded Access Width : 00 [Undefined/Legacy]
[0ECh 0236 008h]                     Address : 0000000000000000


[0F4h 0244 00Ch]      Sleep Control Register : [Generic Address Structure]
[0F4h 0244 001h]                    Space ID : 01 [SystemIO]
[0F5h 0245 001h]                   Bit Width : 08
[0F6h 0246 001h]                  Bit Offset : 00
[0F7h 0247 001h]        Encoded Access Width : 00 [Undefined/Legacy]
[0F8h 0248 008h]                     Address : 0000000000000000

[100h 0256 00Ch]       Sleep Status Register : [Generic Address Structure]
[100h 0256 001h]                    Space ID : 01 [SystemIO]
[101h 0257 001h]                   Bit Width : 08
[102h 0258 001h]                  Bit Offset : 00
[103h 0259 001h]        Encoded Access Width : 00 [Undefined/Legacy]
[104h 0260 008h]                     Address : 0000000000000000

/**** ACPI table terminates in the middle of a data structure! (dump table)
CurrentOffset: 10C, TableLength: 10C ***/
Raw Table Data: Length 268 (0x10C)

    0000: 46 41 43 50 0C 01 00 00 05 ED 48 50 20 20 20 20  // FACP......HP
    0010: 50 72 6F 4C 69 61 6E 74 01 00 00 00 48 50 20 20  // ProLiant....HP
    0020: 01 00 00 00 00 10 58 7B 00 20 7E 7B 00 04 09 00  // ......X{. ~{....
    0030: B2 00 00 00 A0 A1 00 00 00 04 00 00 00 00 00 00  // ................
    0040: 04 04 00 00 00 00 00 00 50 04 00 00 08 04 00 00  // ........P.......
    0050: 20 04 00 00 00 00 00 00 04 02 01 04 10 00 00 00  //  ...............
    0060: 65 00 E9 03 00 00 00 00 01 00 0D 00 32 33 00 00  // e...........23..
    0070: A5 04 00 00 01 08 00 01 F9 0C 00 00 00 00 00 00  // ................
    0080: 06 00 00 00 00 00 00 00 00 00 00 00 00 20 7E 7B  // ............. ~{
    0090: 00 00 00 00 01 20 00 02 00 04 00 00 00 00 00 00  // ..... ..........
    00A0: 01 00 00 00 00 00 00 00 00 00 00 00 01 10 00 02  // ................
    00B0: 04 04 00 00 00 00 00 00 01 00 00 00 00 00 00 00  // ................
    00C0: 00 00 00 00 01 08 00 00 50 04 00 00 00 00 00 00  // ........P.......
    00D0: 01 20 00 03 08 04 00 00 00 00 00 00 01 80 00 01  // . ..............
    00E0: 20 04 00 00 00 00 00 00 01 00 00 00 00 00 00 00  //  ...............
    00F0: 00 00 00 00 01 08 00 00 00 00 00 00 00 00 00 00  // ................
    0100: 01 08 00 00 00 00 00 00 00 00 00 00              // ............


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Andrew Cooper]

On 15/06/2026 3:39 pm, Anthony PERARD wrote:
> [06Ah 0106 001h]         RTC Day Alarm Index : 0D
> [06Bh 0107 001h]       RTC Month Alarm Index : 00
> [06Ch 0108 001h]           RTC Century Index : 32
> [06Dh 0109 002h]  Boot Flags (decoded below) : 0033
>                Legacy Devices Supported (V2) : 1
>             8042 Present on ports 60/64 (V2) : 1
>                         VGA Not Present (V4) : 0
>                       MSI Not Supported (V4) : 0
>                 PCIe ASPM Not Supported (V4) : 1
>                    CMOS RTC Not Present (V5) : 1
> [06Fh 0111 001h]                    Reserved : 00
> [070h 0112 004h]       Flags (decoded below) : 000004A5
>       WBINVD instruction is operational (V1) : 1
>               WBINVD flushes all caches (V1) : 0
>                     All CPUs support C1 (V1) : 1
>                   C2 works on MP system (V1) : 0
>             Control Method Power Button (V1) : 0
>             Control Method Sleep Button (V1) : 1
>         RTC wake not in fixed reg space (V1) : 0
>             RTC can wake system from S4 (V1) : 1

There's 3 pieces of information on here which confirm an RTC is
present.  Setting RTC_NOT_PRESENT is clearly a bug.

We should probably have a quirk to ignore RTC_NOT_PRESENT on this system.

~Andrew

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Jan Beulich]

On 15.06.2026 19:02, Andrew Cooper wrote:
> On 15/06/2026 3:39 pm, Anthony PERARD wrote:
>> [06Ah 0106 001h]         RTC Day Alarm Index : 0D
>> [06Bh 0107 001h]       RTC Month Alarm Index : 00
>> [06Ch 0108 001h]           RTC Century Index : 32
>> [06Dh 0109 002h]  Boot Flags (decoded below) : 0033
>>                Legacy Devices Supported (V2) : 1
>>             8042 Present on ports 60/64 (V2) : 1
>>                         VGA Not Present (V4) : 0
>>                       MSI Not Supported (V4) : 0
>>                 PCIe ASPM Not Supported (V4) : 1
>>                    CMOS RTC Not Present (V5) : 1
>> [06Fh 0111 001h]                    Reserved : 00
>> [070h 0112 004h]       Flags (decoded below) : 000004A5
>>       WBINVD instruction is operational (V1) : 1
>>               WBINVD flushes all caches (V1) : 0
>>                     All CPUs support C1 (V1) : 1
>>                   C2 works on MP system (V1) : 0
>>             Control Method Power Button (V1) : 0
>>             Control Method Sleep Button (V1) : 1
>>         RTC wake not in fixed reg space (V1) : 0
>>             RTC can wake system from S4 (V1) : 1
> 
> There's 3 pieces of information on here which confirm an RTC is
> present.  Setting RTC_NOT_PRESENT is clearly a bug.
> 
> We should probably have a quirk to ignore RTC_NOT_PRESENT on this system.

Imo we should go that far only if EfiGetTime() didn't work there. Afaics
Linux also has no such quirk.

Jan

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Roger Pau Monné]

On Tue, Jun 16, 2026 at 08:16:41AM +0200, Jan Beulich wrote:
> On 15.06.2026 19:02, Andrew Cooper wrote:
> > On 15/06/2026 3:39 pm, Anthony PERARD wrote:
> >> [06Ah 0106 001h]         RTC Day Alarm Index : 0D
> >> [06Bh 0107 001h]       RTC Month Alarm Index : 00
> >> [06Ch 0108 001h]           RTC Century Index : 32
> >> [06Dh 0109 002h]  Boot Flags (decoded below) : 0033
> >>                Legacy Devices Supported (V2) : 1
> >>             8042 Present on ports 60/64 (V2) : 1
> >>                         VGA Not Present (V4) : 0
> >>                       MSI Not Supported (V4) : 0
> >>                 PCIe ASPM Not Supported (V4) : 1
> >>                    CMOS RTC Not Present (V5) : 1
> >> [06Fh 0111 001h]                    Reserved : 00
> >> [070h 0112 004h]       Flags (decoded below) : 000004A5
> >>       WBINVD instruction is operational (V1) : 1
> >>               WBINVD flushes all caches (V1) : 0
> >>                     All CPUs support C1 (V1) : 1
> >>                   C2 works on MP system (V1) : 0
> >>             Control Method Power Button (V1) : 0
> >>             Control Method Sleep Button (V1) : 1
> >>         RTC wake not in fixed reg space (V1) : 0
> >>             RTC can wake system from S4 (V1) : 1
> > 
> > There's 3 pieces of information on here which confirm an RTC is
> > present.  Setting RTC_NOT_PRESENT is clearly a bug.
> > 
> > We should probably have a quirk to ignore RTC_NOT_PRESENT on this system.
> 
> Imo we should go that far only if EfiGetTime() didn't work there. Afaics
> Linux also has no such quirk.

Linux also checks for the presence of a device in ACPI tables with the
ID "ACPI000E", and attaches the RTC driver to it.  We can't do this
on Xen.

Thanks, Roger.

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Anthony PERARD]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

On Fri, Jun 12, 2026 at 04:11:28PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Jun 12, 2026 at 03:53:49PM +0200, Anthony PERARD wrote:
> > Hi,
> > 
> > Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
> > a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
> > netbooted and EFI.
> > 
> > Xen call trace:
> >    [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
> >    [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
> >    [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
> >    [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
> >    [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
> >    [<ffff82d0402043e7>] F __high_start+0xb7/0xc0
> > 
> > Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
> > 
> > A few more lines from Xen:
> >     CPU Vendor: Intel, Family 6 (0x6), Model 86 (0x56), Stepping 3 (raw 00050663)
> >     Bootloader: GRUB 2.06
> >     [...]
> >     Enabling APIC mode.  Using 2 I/O APICs
> >     ENABLING IO-APIC IRQs
> >      -> Using old ACK method
> >      ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
> >     TSC deadline timer enabled
> >     Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195
> > 
> > Commit this Xen is built from: 50936ea05660.
> 
> Interesting, the efi_get_time() way is nowadays a fallback if cmos one
> isn't advertised. Can you try adding `cmos-rtc-probe`?

Yep, that works. I could boot the machine. There's not much changes in
the logs, beside different memory mapping, and otherwise this:

    TSC deadline timer enabled
    Wallclock source: CMOS RTC
    Allocated console ring of 128 KiB.
    mwait-idle: MWAIT substates: 0x2120
    mwait-idle: lapic_timer_reliable_states 0x2
    HPET: 8 timers usable for broadcast (8 total)
    [... the rest of the boot]

Thanks,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: Assertion '!is_idle_vcpu(v)' failed after 'Remove fully_eager_fpu' commit on EFI

[Jan Beulich]

On 12.06.2026 15:53, Anthony PERARD wrote:
> Since commit dba44e051209 ("x86: Remove fully_eager_fpu"), I can't boot
> a machine and get assertion '!is_idle_vcpu(v)' failed instead. It's
> netbooted and EFI.
> 
> Xen call trace:
>    [<ffff82d04033da2c>] R vcpu_save_fpu+0x65/0xdc
>    [<ffff82d04029c5c4>] S efi_rs_enter+0x37/0x16a
>    [<ffff82d04029c7e3>] F efi_get_time+0x19/0xb2
>    [<ffff82d04047cbf0>] F init_xen_time+0x1e3/0x2b4
>    [<ffff82d040477a49>] F __start_xen+0x1d71/0x24b8
>    [<ffff82d0402043e7>] F __high_start+0xb7/0xc0
> 
> Assertion '!is_idle_vcpu(v)' failed at arch/x86/i387.c:195

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

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

[Bernhard Kaindl]

[-- Attachment #1: Type: text/plain, Size: 3577 bytes --]

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@vates.tech>
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Bernhard Kaindl <bernhard.kaindl@citrix.com>
---
  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

[-- Attachment #2: Type: text/html, Size: 7191 bytes --]

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

[Anthony PERARD]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Fri, Jun 12, 2026 at 05:41:07PM +0200, Bernhard Kaindl wrote:
> Hi Anthony, could you test this patch which exactly applies the changes Jan
> suggested? Summary:

Sure but could you use `git send-email` to send patch please? Trying to
apply this email is not fun. The patch part is just corrupted. I might
try to edit the source by hand...

If you have a good setup, sending a patch is really just `git send-email
-1`, if you want to send it as a reply to an email, there's
`--in-reply-to` for that, but that's not really necessary, and sometime
counter productive. And no need to for `--cc` to CC me, has `git` can
also pick that up from the "reported-by". ;-)

If you want to add comments to a patch, and not have it committed, do not
use "PS:" after a signature. Add it between the "---" line and the first
line starting by "diff ", like git do with the diffstat.

Cheers,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

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

[Jan Beulich]

On 12.06.2026 17:41, Bernhard Kaindl wrote:
> Hi Anthony, could you test this patch which exactly applies the changes 
> Jan suggested? Summary:

So I'm a little irritated by this: The subject suggests this is a proper
patch submission, yet about everything else here suggests it is not. For
the eventual real patch, may I minimally suggest ...

> 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

... to resolve this line number to a function name, to provide sufficient
context.

> 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.

I further would help if it was explicitly stated that no other uses of
the two functions are affected (provided the necessary auditing was done,
but ftoad I did go through that already on Friday and didn't find other
problematic call sites).

Jan

> Fixes: 1792bb9a99d2 ("x86: Cleanup cr0.TS flag handling")
> Fixes: dba44e051209 ("x86: Remove fully_eager_fpu")
> Reported-by: Anthony PERARD <anthony.perard@vates.tech>
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@citrix.com>
> ---
>   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)

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

[Oleksii Kurochko]

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@vates.tech>
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Bernhard Kaindl <bernhard.kaindl@citrix.com>
> ---


Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Thanks.

~ Oleksii