Re: [RFC PATCH 1/4] acpi: fix acpi_send_gpe_event() to handle more events

2026-02-03 Thread David Woodhouse
On Mon, 2025-12-01 at 12:50 +, Chalios, Babis wrote:
> acpi_send_gpe_events() sends events encoded in the AcpiEventStatusBits
> enum. The maximum bit used so far in the latter was 128, hence a single
> byte (ACPIGPE.sts[0]) is currently enough to hold the set bits.
> 
> When we add an extra one, we will need a second byte to encode the state
> and casting from AcpiEventStatusBits to uint8_t will silently ignore the
> higher bits.
> 
> Fix this, by taking into account the length value inside ACPIGPE.
> 
> Signed-off-by: Babis Chalios 
> ---
>  hw/acpi/core.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/acpi/core.c b/hw/acpi/core.c
> index ff16582803..48694eca54 100644
> --- a/hw/acpi/core.c
> +++ b/hw/acpi/core.c
> @@ -730,7 +730,13 @@ uint32_t acpi_gpe_ioport_readb(ACPIREGS *ar, uint32_t 
> addr)
>  void acpi_send_gpe_event(ACPIREGS *ar, qemu_irq irq,
>   AcpiEventStatusBits status)
>  {
> -    ar->gpe.sts[0] |= status;
> +    int i;
> +
> +    for (i = 0; i < ar->gpe.len; i++) {
> +    ar->gpe.sts[i] |= (status & 0xff);
> +    status >>= 8;
> +    }
> +
>  acpi_update_sci(ar, irq);
>  }
>  

Testing with the guest code that's now merged into net-next, I see that
still doesn't actually raise the SCI. It needs this in
acpi_update_sci():

--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -741,13 +741,16 @@ void acpi_send_gpe_event(ACPIREGS *ar, qemu_irq irq,
 
 void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
 {
-int sci_level, pm1a_sts;
+int i, sci_level, pm1a_sts;
 
 pm1a_sts = acpi_pm1_evt_get_sts(regs);
 
 sci_level = ((pm1a_sts &
-  regs->pm1.evt.en & ACPI_BITMASK_PM1_COMMON_ENABLED) != 0) ||
-((regs->gpe.sts[0] & regs->gpe.en[0]) != 0);
+  regs->pm1.evt.en & ACPI_BITMASK_PM1_COMMON_ENABLED) != 0);
+
+for (i = 0; !sci_level && i < regs->gpe.len; i++) {
+sci_level = ((regs->gpe.sts[i] & regs->gpe.en[i]) != 0);
+}
 
 qemu_set_irq(irq, sci_level);
 

I'll send a new series with that fixed, and with an independent local
vmclock-abi.h header instead of using the one from Linux. And maybe
some QMP/HMP commands for the toolstack to bump the disruption and
generation counters.


smime.p7s
Description: S/MIME cryptographic signature


[RFC PATCH 1/4] acpi: fix acpi_send_gpe_event() to handle more events

2025-12-01 Thread Chalios, Babis
acpi_send_gpe_events() sends events encoded in the AcpiEventStatusBits
enum. The maximum bit used so far in the latter was 128, hence a single
byte (ACPIGPE.sts[0]) is currently enough to hold the set bits.

When we add an extra one, we will need a second byte to encode the state
and casting from AcpiEventStatusBits to uint8_t will silently ignore the
higher bits.

Fix this, by taking into account the length value inside ACPIGPE.

Signed-off-by: Babis Chalios 
---
 hw/acpi/core.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index ff16582803..48694eca54 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -730,7 +730,13 @@ uint32_t acpi_gpe_ioport_readb(ACPIREGS *ar, uint32_t addr)
 void acpi_send_gpe_event(ACPIREGS *ar, qemu_irq irq,
  AcpiEventStatusBits status)
 {
-ar->gpe.sts[0] |= status;
+int i;
+
+for (i = 0; i < ar->gpe.len; i++) {
+ar->gpe.sts[i] |= (status & 0xff);
+status >>= 8;
+}
+
 acpi_update_sci(ar, irq);
 }
 
-- 
2.34.1