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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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