better emulate PM1 registers

[pfmooney]

When booting Linux (depending on the kernel version), some ACPI errors are emitted:

[    0.386017][    T1] ACPI Error: Could not enable GlobalLock event (20230628/evxfevnt-182)
[    0.387055][    T1] ACPI Error: No response from Global Lock hardware, disabling lock (20230628/evglock-59)
[    0.926299][    T1] ACPI Error: Could not enable RealTimeClock event (20230628/evxfevnt-182)

The ACPI logic is attempting to enable the SCI bits for GBL_EN and RTC_EN, which we currently pay no heed to. The former would likely be trivial to support, since I do not believe there is Global Lock activity from the firmware, and thus no source for such events. The latter poses more of a challenge, since we have no way of wiring up RTC events into the emulated power management device. Allowing the guest to enable such events might be a cruel lie, if they will never arrive.

[glitzflitz]

I ran into these while working on #999 and decided to dig deeper.
For GlobalLock the problem is PmSts and PmEn flags in i440fx only define PWRBTN_STS/PWRBTN_EN. In pmreg_write(), PmEn::from_bits_truncate(wo.read_u16())

propolis/lib/propolis/src/hw/chipset/i440fx.rs

Line 943 in f969fb7

regs.pm_ena = PmEn::from_bits_truncate(wo.read_u16());

masks the incoming value against defined flags, so GBL_EN and RTC_EN get masked out. So the guest reads back zero and assumes the hardware refused to enable the events.

Looks like the bhyve already handles RTC periodic and alarm interrupts, which pulses IRQ 8 via vatpic_pulse_irq() and vioapic_pulse_irq() in vrtc_regc_update() https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/intel/io/vmm/io/vrtc.c#L856
I think i440fx emulation could just reflect the interrupt status in PM1_STS and pulse SCI when IRQF is set and RTC_EN is enabled.

[glitzflitz]

Looks like SCI is not wired up yet

propolis/lib/propolis/src/hw/chipset/i440fx.rs

Line 106 in f969fb7

// XXX: wire up SCI notifications

Let me see if I can wire it up and do the PM1_STS status handling.

[glitzflitz]

We already have rtc_read()

propolis/lib/propolis/src/vmm/hdl.rs

Line 308 in f969fb7

pub fn rtc_read(&self, offset: u8) -> Result<u8> {

so we could just read reg C and check IRQF there and pulse the SCI after wiring it up.

[pfmooney]

There is not a great way to hook into the PMTMR overflow today, for surfacing an SCI on that event.

Reflecting RTC_STS in PMSTS would be fairly straightforward, but if you query that status via rtc_read(), you'll be clearing the interrupt flag (see vrtc_regc_read()).

[glitzflitz]

I see so only way to fix this would be, in bhyve to support non destructive RTC status query so we can call something like rtc_peek() or bhyve to send the notification to userspace on RTC events.
Or bhyve could just update PmSts and pulse SCI when RTC fires by itself...

[pfmooney]

I see so only way to fix this would be, in bhyve to support non destructive RTC status query so we can call something like rtc_peek()

Technically possible today with the VMM_DATA_READ interface to dump the entire vRTC state, but that's a little clunky. Adding rtc_peek() to the API might make more sense for what we're trying to accomplish here.

or bhyve to send the notification to userspace on RTC events.

In the large, I think we should consider how the kernel vmm portion of bhyve might expose events like that from the devices it's emulating. The PM timer rollover would be another useful one in this area.

Or bhyve could just update PmSts and pulse SCI when RTC fires by itself...

Is an SCI interrupt for assertion of the RTC interrupt state proper? I see SCIs for many of the other PMSTS bits, but the RTC one cites only IRQ8.

[glitzflitz]

Is an SCI interrupt for assertion of the RTC interrupt state proper? I see SCIs for many of the other PMSTS bits, but the RTC one cites only IRQ8.

As per the ACPI spec (Section 4.8.2.4) https://uefi.org/specs/ACPI/6.5_A/04_ACPI_Hardware_Specification.html#real-time-clock-alarm

When the RTC generates a wake event the RTC_STS bit will be set. If the RTC_EN bit is set, an RTC hardware power management event will be generated"

And Table 4.11 https://uefi.org/specs/ACPI/6.5_A/04_ACPI_Hardware_Specification.html#pm1-status-registers-fixed-hardware-feature-status-bits

if the RTC_EN bit is set then the setting of the RTC_STS bit will generate a power management event (an SCI, SMI, or resume event)

also

"The RTC_STS bit may be set through the RTC interrupt (IRQ8 in IA-PC architecture systems)"

So as I understand intended flow is:

1. RTC alarm fires -> IRQ8 pulses
2. Hardware sets RTC_STS in PM1_STS
3. If RTC_EN is set -> SCI fires (IRQ9)

Looks like qemu does the similar thing
https://github.com/qemu/qemu/blob/159107e390609f71b78268a4888563dcdce6ac65/hw/acpi/core.c#L743

acpi_update_sci()
    sci_level = ((pm1a_sts &
                  regs->pm1.evt.en & ACPI_BITMASK_PM1_COMMON_ENABLED) != 0) ||
                ((regs->gpe.sts[0] & regs->gpe.en[0]) != 0);

    qemu_set_irq(irq, sci_level);