On 3/4/25 7:00 AM, Mario Limonciello wrote:
On 3/3/2025 17:48, samasth.norway.ananda@xxxxxxxxxx wrote:
Hi,
We recently observed that the LTP rtc01 RTC alarm test fails on intel
based VM's. This seems to be observed after the commit
6492fed7d8c95f53b0b804ef541324d924d95d41 - ("rtc: rtc-cmos: Do not
check ACPI_FADT_LOW_POWER_S0")
I noticed that the use_acpi_alarm was set to "N" before the commit,
now it is set as "Y"
# cat /sys/module/rtc_cmos/parameters/use_acpi_alarm
Y
#./runltp -d /tmpdir -s rtc01
<<<test_output>>>
incrementing stop
rtc01 0 TINFO : RTC READ TEST:
rtc01 1 TPASS : RTC READ TEST Passed
rtc01 0 TINFO : Current RTC date/time is 3-3-2025, 21:02:20.
rtc01 0 TINFO : RTC ALARM TEST :
rtc01 0 TINFO : Alarm time set to 21:02:25.
rtc01 0 TINFO : Waiting 5 seconds for the alarm...
rtc01 2 TFAIL : rtc01.c:151: Timed out waiting for the alarm
rtc01 0 TINFO : RTC UPDATE INTERRUPTS TEST :
rtc01 0 TINFO : Waiting for 5 update interrupts...
rtc01 3 TFAIL : rtc01.c:208: Timed out waiting for the update
interrupt
rtc01 0 TINFO : RTC Tests Done!
I believe that the hypervisor may not fully support ACPI or may
implement it differently than physical hardware. ACPI wake-up events
may not be properly supported or may be emulated differently in the
VM, causing alarms to not trigger correctly or time out.
On AMD all instances the use_acpi_alarm is set to "N" so no issue seen.
On intel Bare metal instances the use_acpi_alarm is set to "Y" but no
issue seen.
But, on intel VM's the use_acpi_alarm is set to "Y" and the issue is
seen.
I even check with
# acpidump > acpidump.txt
# grep "FADT" acpidump.txt
no output from above saying that ACPI_FADT_LOW_POWER_S0 is not set.
Is it possible to know we can address this issue? Should we make
changes in the LTP test itself? or in the kernel?
I'm a bit surprised it didn't also affect AMD; but maybe that's because
of the specific date of the "BIOS" for the VM.
To me this sounds like a hypervisor bug though. Could you add a
condition to detect this hypervisor and exclude it (and also report it
to the vendor for the hypervisor "BIOS")?
It's not affecting AMD because of the first check as below in the
use_acpi_alarm_quirks() function.
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
return;
In AMD systems we return control right here and the use_acpi_alarm is
never set to true. But for intel the above condition wont pass.
I added a check to find the hypervisor
cpuid(1, &eax, &ebx, &ecx, &edx);
if (ebx == 0x756e6547 && ecx == 0x6c65746e && edx == 0x49656e69)
hypervisor_name = "KVM";
I was able to detect the Hypervisor to be KVM. Do you think that the
issue is due to KVM?
Thanks,
Samasth.
