The acpi service evaluates _CRS/_STA in ring 3 and reports devices (M20.2)

AML method evaluation now runs in userspace touching real hardware: the
service builds an interpreter with a ring-3 Hal (port I/O routed through
its claimed acpi-tables node; a scratch page backs SystemMemory maps so a
stray OperationRegion degrades to zeros instead of faulting a process
that cannot map arbitrary physical memory). It walks the namespace and,
for each present _HID device that is not a PCI root, evaluates _CRS,
registers it under acpi-tables, and reports it with its EISA-decoded hid.

Containment for this needed the broker's irq check to become range-based
— an interrupt line is still indivisible, but a parent may own a range,
so the acpi-tables node's broad irq window contains its children's legacy
lines (a length-1 range is exactly the old equality, so single-irq
parents are unaffected). ChildAdded gained a hid field for firmware
string identity. Matching those reports to drivers stays off until M20.3,
so ps2-bus still comes up via the kernel path — no regression. The
acpi-report scenario proves the PS/2 keyboard (io 0x60/0x64 + IRQ) and
mouse (IRQ) are reported with their resources. Suite 57/57.

system/kernel/tests.zig

@@ -148,6 +148,8 @@ pub fn run(case: []const u8, boot_information: *const BootInformation) void {
         pciScanTest(boot_information);
     } else if (eql(case, "acpi-parse")) {
         acpiParseTest(boot_information);
+    } else if (eql(case, "acpi-report")) {
+        acpiReportTest(boot_information);
     } else if (eql(case, "initial-ramdisk")) {
         initialRamdiskTest(boot_information);
     } else if (eql(case, "vfs")) {
@@ -1914,6 +1916,38 @@ fn pciScanTest(boot_information: *const BootInformation) void {
     result();
 }
 
+/// M20.2: the acpi service registers + reports its _HID devices. Boot normally
+/// (the manager spawns discovery); the harness's expect regex requires the two
+/// PS/2 nodes among the service's report lines, each with its _CRS resources —
+/// the ring-3 _CRS/_STA evaluation working end to end. The kernel test only
+/// starts the manager.
+fn acpiReportTest(boot_information: *const BootInformation) void {
+    log("DANOS-TEST-BEGIN: acpi-report\n", .{});
+    if (boot_information.initial_ramdisk_len == 0) {
+        check("bootloader handed over an initial_ramdisk", false);
+        result();
+        return;
+    }
+    const image = @as([*]const u8, @ptrFromInt(boot_handoff.physicalToVirtual(boot_information.initial_ramdisk_base)))[0..boot_information.initial_ramdisk_len];
+    const rd = initial_ramdisk.Reader.init(image) orelse {
+        check("initial_ramdisk image is valid", false);
+        result();
+        return;
+    };
+    process.setInitialRamdisk(image);
+    var spawned = false;
+    var i: u32 = 0;
+    while (i < rd.count) : (i += 1) {
+        const item = rd.entry(i) orelse continue;
+        if (!eql(item.name, "device-manager")) continue;
+        _ = process.spawnProcessSupervised(item.blob, 4, &.{"device-manager"}, scheduler.currentId(), null) catch 0;
+        spawned = true;
+        break;
+    }
+    check("device-manager spawned", spawned);
+    result();
+}
+
 /// M20.1: the ring-3 AML parse agrees with the kernel's. The manager spawns
 /// the discovery service (the acpi build variant); it claims the acpi-tables
 /// node, maps the blobs, parses them, and logs its Device count — which must