# DF-5651 — SRAT proximity-domain association compares only the low byte (ProximityDomainLo), ignoring ProximityDomainHi and x2APIC entries

## What

`sys/platform/pc64/acpica/acpi_srat.c:112-113` and `:124-125` associate a
MEMORY affinity entry with a CPU affinity entry by comparing the memory
entry's full 32-bit `ProximityDomain` (packed u32@+2) against the CPU
entry's **one-byte** `ProximityDomainLo` (packed u8@+2):

```c
if (cpu == NULL ||
    mem->mem.ProximityDomain != cpu->cpu.ProximityDomainLo) {   /* :113 */
```

The rev-1 CPU entry's upper three domain bytes (`ProximityDomainHi[3]`,
actbl3.h:377, packed @+9) are never consulted, and rev-2+ x2APIC CPU
entries (`ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY`, Type 2, 32-bit domain +
32-bit APIC ID) are not handled at all (`:118-120` dispatches only
Type 0).

## Effect (correctness/perf, no memory-safety impact)

- Any proximity domain >= 256 can never match a rev-1 CPU entry whose low
  byte happens to differ → the range prints "(not found)"
  (acpi_srat.c:140) and `vm_numa_organize()` is never called for it.
- Worse, a domain like 0x0100 collides with Lo=0x00 of an unrelated socket
  → memory is organized under the **wrong chip's** page-color domain
  (vm_page.c:546-547), cross-node memory placement for the machine's life.
- On systems whose firmware only emits x2APIC CPU entries (legal since
  ACPI 4.0, required for APIC IDs > 255), no CPU entry ever matches and no
  SRAT memory range is ever organized — the NUMA code silently no-ops.

No memory corruption, leak, or privilege boundary is crossed: `physid`
derived from the matched `ApicId` (u8) is bounded (`mod
cpu_topology_phys_ids`, vm_page.c:547). Filed as Info (correctness gap /
silent NUMA misdirection), untested on hardware that exposes it.

## Suggested fix

Compare the CPU entry's full 20-bit domain
(`ProximityDomainHi[3]<<8 | ProximityDomainLo`) against
`mem->mem.ProximityDomain`, and handle Type-2 x2APIC entries' 32-bit
domain/APIC ID.