The local APIC runs in xAPIC mode where CPUID offers no x2APIC

issues/the-xapic-icr-send-polls-no-delivery-status-and-no-machine-has-read-it.md

@@ -0,0 +1,26 @@
+---
+status: open
+kind: tooling
+opened: 2026-10-10
+---
+
+# The xAPIC ICR send polls no Delivery Status, and no machine has read it
+
+`arch::apic::send` writes an xAPIC ICR's destination half and then its command
+half without first polling Delivery Status (bit 12). AMD APM Vol. 2 §16.5
+lets software write `ICRL` again without polling it, and Intel SDM Vol. 3A
+§13.6.1 states no wait; Linux's `default_send_IPI_single_phys` polls anyway.
+Whether a send can still be pending is the hardware's, and TCG
+(`desktop_without_x2apic`) emulates none of it. The one xAPIC machine that has
+run this path is the AMD Zen 2 laptop, which booted 16 of 16 CPUs through the
+INIT-SIPI-SIPI sends and ran to its power-off, but its reading counts no
+machine-wide shootdown, whose all-but-self IPI is the send
+that would race a previous one: the stop says the census, `tlb: shootdowns=…`
+among it, after logkeeper's last write (`syscall::machine`), so the laptop's
+`/log` cannot carry it.
+
+Owner: the orchestrator, which holds the laptop. Exit: a laptop boot's
+`tlb: shootdowns=…` line, read off whatever channel carries the census
+there, counts at least one shootdown, and that boot reaches its stop with no
+`tlb: cpu … has not flushed` panic; or a lost IPI on it is traced to the
+missing poll and the poll is added.

issues/vtd-keeps-eime-off-under-an-xapic-and-no-test-reaches-it.md

@@ -0,0 +1,21 @@
+---
+status: open
+kind: defect
+opened: 2026-10-10
+---
+
+# VT-d keeps `EIME` off under an xAPIC, and no test reaches it
+
+`arch::x86_64::vtd::remappable` sets extended interrupt mode only where every
+unit reports `ECAP.EIM` and the local APICs run x2APIC, because an xAPIC
+compares the 8-bit destination field (VT-d Rev. 4.1 Section 9.9). No tier runs
+the xAPIC arm beside VT-d: QEMU's `intel-iommu` takes `eim=on` only with KVM's
+split irqchip, the harness's default leaves `eim` off, the T14 runs x2APIC and
+the AMD laptop has AMD-Vi, not VT-d. So the `x2apic &&` term passes every test
+with it deleted.
+
+Owner: the IOMMU track, beside
+`issues/x2apic-is-enabled-without-reading-firmwares-opt-out.md`, whose exit
+runs xAPIC on the T14. Exit: a T14 row boots its CPUs in xAPIC on its VT-d
+unit, which reports `ECAP.EIM`, reads `EIME` off in the unit's log, and goes
+red with the `x2apic &&` term deleted.

kernel/pure/sched/hw.rs

@@ -4,7 +4,7 @@
 //! task-blind surface (clock, one-shot timer, interrupt gate, halt, trace);
 //! [`Hw`] adds the two operations that carry a task — the context switch and
 //! the finalize sink. The kernel implements them with LAPIC one-shot,
-//! targeted x2APIC ICR, TSC and the asm switch; the simulator over a virtual
+//! targeted ICR, TSC and the asm switch; the simulator over a virtual
 //! clock and vcpu bookkeeping. No scheduling decision, state transition or
 //! ordering-sensitive code may live behind them.