acpica: use platform session for accessing I/O resources only

[chelmuth]

Currently, acpica requests its required resources (SCI IRQ, ACPI tables, potentially IOMEM and IOPORT) from core directly. This approach races with the initialization of acpi_drv/pci_decode/platform_drv and does not properly constrain the effect of acpica processing.

[ttcoder]

A data point FWIW, on the small chance that this is relevant to this ticket : last week, doing a run (might have been on bare metal) as usual, the boot-up failed very early with a half page of red error() lines related to acpi and acpica (didn't take a photo of the screen...). I never saw that happen again. If it was a deterministic occurence it wouldn't be remarkable, but a bug that occurs "once in a blue moon" would I guess support the idea of a race condition.

[nfeske]

Thanks for the data point. We encountered similar sporadic issues (i.e., #4641) that seem to be related.

Today, we added 66491dd to staging, which tightens the order between the initial ACPI and PCI discovery and the startup of the drivers (including acpica). With this change, the start of acpica gets deferred until the PCI discovery by pci_decode is complete.

[cnuke]

Sorry for hijacking this issue,

Today, we added 66491dd to staging, which tightens the order between the initial ACPI and PCI discovery and the startup of the drivers (including acpica). With this change, the start of acpica gets deferred until the PCI discovery by pci_decode is complete.

for unrelated reasons I tried to execute the acpica.run run-script on hardware (X250) on HEAD fe9c5bd and it failed in the following way:

[…]
7816 MiB RAM and 63253 caps assigned to init
[init -> platform_drv] Error: ROM-session creation failed (ram_quota=6144, cap_quota=3, label="devices")
[init -> platform_drv] Error: Could not open ROM session for "devices"
[init -> platform_drv] Error: Uncaught exception of type 'Genode::Rom_connection::Rom_connection_failed'
[init -> acpica]   0x1000000 .. 0x10ffffff: linker area
[init -> acpica]   0x40000000 .. 0x4fffffff: stack area
[init -> acpica]   0x30000 .. 0x14dfff: ld.lib.so
[…]

With commit c3a7777 it fails in a different way:

7816 MiB RAM and 63253 caps assigned to init
[init -> acpica]   0x1000000 .. 0x10ffffff: linker area
[init -> acpica]   0x40000000 .. 0x4fffffff: stack area
[init -> acpica]   0x30000 .. 0x14dfff: ld.lib.so
Error: I/O memory [00000000ccdfe000,00000000ccdff000) not available
Error: Local MMIO mapping failed!
[init -> acpi_drv] Found MADT
[init -> acpi_drv] MADT IRQ 0 -> GSI 2 flags: 0
[init -> acpi_drv] MADT IRQ 9 -> GSI 9 flags: 13
[init -> acpi_drv] Found MCFG
[init -> acpi_drv] MCFG BASE 0xf8000000 seg 0x0 bus 0x0-0x3f
[init -> usb_hid_drv] --- USB HID input driver ---
[init -> usb_hid_drv] Warning: use compatibility mode: will claim all HID devices from USB report
[init -> acpica] Error: IO_MEM-session creation failed (cap_quota=3, ram_quota=6144, base=0xccdfe000, size=0x1000, wc=no)
[init -> acpica] Error: AcpiInitializeTables failed, status=4
[init -> dynamic_rom] system: change (set system state to 'normal')
[init -> dynamic_rom] system: sleep 5000 milliseconds
[init -> acpica] Warning: no IRQ handling available
[init -> acpi_drv] Found DMAR

For better or worse it appears to work on QEMU but that might be happening by chance. Adding a lower priority to acpica remedies the problem on hardware.

[alex-ab]

With 2a025de and f3ab17d an explicit dependency on a device is added to defer acpica until the pci_decode and the new platform driver could claim all resources.