fix(pci-ids): keep ich9 sata at 1f.2 so ovmf-booted guests find the disk

This commit is contained in:
2026-10-10 03:57:09 +02:00
parent d94772ddc2
commit 8b77a135ec
3 changed files with 30 additions and 11 deletions
+25 -1
View File
@@ -105,7 +105,9 @@ Links, in order:
5. ~~FACP C2/C3 latencies, vmaware.hpp:9242~~ - `0xfff` -> `0xffe` 5. ~~FACP C2/C3 latencies, vmaware.hpp:9242~~ - `0xfff` -> `0xffe`
6. Debug Port OperationRegion at `0x0402` - already dead on this tree 6. Debug Port OperationRegion at `0x0402` - already dead on this tree
7. HPET register-validation loop - dormant, domain sets `hpet present='no'`. Re-arms if enabled. 7. HPET register-validation loop - dormant, domain sets `hpet present='no'`. Re-arms if enabled.
8. Dummy SATA, DMAR, APIC source overrides - already dead on this tree 8. Dummy SATA, DMAR, APIC source overrides - dead on this tree (SATA at `1f.2`: see the SATA
subsection below - device 31's functions carry no generic `_ADR` node, so the `D0FA`+`0x1F0002`
pair never forms)
Link 3 requires **all four** of `LNKE`, `LNKH`, `GSIE`, `GSIH`, which is QEMU's eight-link plus Link 3 requires **all four** of `LNKE`, `LNKH`, `GSIE`, `GSIH`, which is QEMU's eight-link plus
eight-GSI layout. Real boards have four PCI link devices and no GSI-named ones, so rename the eight-GSI layout. Real boards have four PCI link devices and no GSI-named ones, so rename the
@@ -181,6 +183,28 @@ Verified on QEMU 11.1.2 with this fix in the default series: the DSDT keeps `\_S
login and powers off via S5 in ~12 s; VMAware v2.8.1 and HEAD both report `detected=0` / `FIRMWARE=0` login and powers off via S5 in ~12 s; VMAware v2.8.1 and HEAD both report `detected=0` / `FIRMWARE=0`
on the stealth guest; Windows (secboot + SMM) and Linux boot unchanged. The opt-in split is gone. on the stealth guest; Windows (secboot + SMM) and Linux boot unchanged. The opt-in split is gone.
### CLEARED - the SATA controller OVMF must find at 1f.2 (`03-pci-ids`, 1.4.1)
`03-pci-ids` originally relocated the ICH9 SATA controller off its standard slot
(`ICH9_SATA1_DEV` 31 -> 20) to move the dummy-SATA DSDT node away from `00:1f.2`. That breaks
OVMF first-boot for any SATA-booted guest: OVMF expects the q35 AHCI at `00:1f.2`, so with it at
`00:14.2` OVMF never builds the disk boot option and falls through to `Start PXE over IPv4`. Only
macOS exposed this - it boots OpenCore off AHCI; the Windows identity guests boot from NVMe and
never touched the moved controller. A/B confirmed it: stock QEMU reaches the OpenCore picker, the
1.4.0 patched binary PXEs, and restoring `ICH9_SATA1_DEV = 31` reaches the picker again
(`BdsDxe: loading ... from PciRoot(0x0)/Pci(0x1F,0x2)/Sata`).
The relocation was never load-bearing for the score. The dummy-SATA FIRMWARE link
(vmaware.hpp ~9963) fires only on **both** the NameSeg `D0FA` **and** `Name(_ADR, 0x001F0002)`.
With SATA back at `1f.2`, neither is present: QEMU describes device 31's functions under the ICH9
LPC/ISA scope, not through `build_append_pci_bus_devices`, so the controller gets no generic
`_ADR` node at all, and `get_mimic_pci_name` never emits `D0FA` for any devfn. Dumped the DSDT of a
`1f.2`-SATA guest on the fixed build: zero `D0FA`, zero `08 5F 41 44 52 0C 02 00 1F 00`. No vendor
or device ID changes, so `DEVICES` / `PCI_VENDOR` / `CPU_HEURISTIC` are untouched.
Fix: drop the `ICH9_SATA1_DEV` hunk, leave SATA at stock `1f.2`. macOS boots on the default series;
0/85 preserved.
--- ---
## CLEARED - CTYPE and SMBIOS_VM_BIT (the SMBIOS QEMU synthesises) ## CLEARED - CTYPE and SMBIOS_VM_BIT (the SMBIOS QEMU synthesises)
+5 -1
View File
@@ -52,7 +52,11 @@ Against QEMU v11.1.2. Apply in numeric order.
The numbered patches are the default series and score 0/85 on both VMAware HEAD and v2.8.1. The numbered patches are the default series and score 0/85 on both VMAware HEAD and v2.8.1.
`03-pci-ids` scopes the virtio subsystem-id change so OVMF still binds virtio (its generic default `03-pci-ids` scopes the virtio subsystem-id change so OVMF still binds virtio (its generic default
goes to Intel/0, virtio devices keep the Red Hat subsystem ids their drivers and OVMF expect). goes to Intel/0, virtio devices keep the Red Hat subsystem ids their drivers and OVMF expect). It
also leaves the ICH9 SATA controller at its stock slot `1f.2`: OVMF locates the q35 AHCI there, so
moving it broke first-boot for SATA-booted UEFI guests (macOS fell through to PXE) while buying
nothing for the score - the dummy-SATA FIRMWARE tell needs both the `D0FA` name and `_ADR 0x1F0002`,
and device 31's functions emit neither. See `docs/ANALYSIS.md`.
`11-macos-cpu-hotplug` makes the series universal: macOS boots (it needs the `\_SB.CPUS.Cxxx` `11-macos-cpu-hotplug` makes the series universal: macOS boots (it needs the `\_SB.CPUS.Cxxx`
objects from `build_cpus_aml`) and both VMAware builds still read bare metal, with no opt-in. The objects from `build_cpus_aml`) and both VMAware builds still read bare metal, with no opt-in. The
-9
View File
@@ -90,15 +90,6 @@ index 2c35dd0..2b6a39c 100644
#define ICH9_LPC_NB_PIRQS 8 /* PCI A-H */ #define ICH9_LPC_NB_PIRQS 8 /* PCI A-H */
#define ICH9_LPC_PMBASE 0x40 #define ICH9_LPC_PMBASE 0x40
@@ -177,7 +177,7 @@ struct ICH9LPCState {
#define ICH9_GPIO_GSI "gsi"
/* D31:F2 SATA Controller #1 */
-#define ICH9_SATA1_DEV 31
+#define ICH9_SATA1_DEV 20
#define ICH9_SATA1_FUNC 2
/* D31:F0 power management I/O registers
@@ -213,7 +213,7 @@ struct ICH9LPCState { @@ -213,7 +213,7 @@ struct ICH9LPCState {
/* D31:F3 SMBus controller */ /* D31:F3 SMBus controller */
#define TYPE_ICH9_SMB_DEVICE "ICH9-SMB" #define TYPE_ICH9_SMB_DEVICE "ICH9-SMB"