The AML interpreter runs in ring 3: the acpi service parses (M20.1)

The AML module becomes a build module compiled into both the kernel (for
the \_S5 sleep state it still needs) and the new acpi service — one
source, two builds, no fork. The kernel publishes a single acpi-tables
node: the DSDT/SSDT blobs as memory resources, a broad io_port grant (the
honest trust boundary — firmware AML names whatever ports it chose, known
only after parsing), and the SCI for the M21 event track. The acpi
service claims the node, maps each blob through the ordinary mmio grant
(which preserves the sub-page offset onto the bytecode), and runs the
same parser the kernel does. It self-verifies its namespace Device count
against the kernel's — 34 = 34 — deterministically via an argv the
acpi-parse test passes, so no racing the shared serial buffer. Parse-only
touches no hardware; OperationRegion evaluation waits for _CRS/_STA in
M20.2. The manager spawns 'discovery' (the neutral ramdisk name) at
startup. Suite 56/56.

test/qemu_test.py

@@ -274,6 +274,13 @@ CASES = [
                r"device-manager: restarting usb-xhci-bus[\s\S]*"
                r"device-manager: child added",
      "fail":   r"DANOS-TEST-RESULT: FAIL"},
+    # M20.1: the ring-3 AML parse (the acpi service maps the blobs and parses
+    # them) finds exactly the Device count the kernel's own parse produced.
+    {"name": "acpi-parse",
+     "smp":    4,
+     "timeout": 60,
+     "expect": r"acpi-parse: ok",
+     "fail":   r"acpi-parse: mismatch|DANOS-TEST-RESULT: FAIL"},
     # M19.1: the ring-3 PCI scan (pci-bus walks the ECAM through its mmio_map
     # grant) finds exactly the functions the kernel's own walk recorded.
     {"name": "pci-scan",