fix(pci-ids): keep ich9 sata at 1f.2 so ovmf-booted guests find the disk
This commit is contained in:
+25
-1
@@ -105,7 +105,9 @@ Links, in order:
|
||||
5. ~~FACP C2/C3 latencies, vmaware.hpp:9242~~ - `0xfff` -> `0xffe`
|
||||
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.
|
||||
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
|
||||
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`
|
||||
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)
|
||||
|
||||
+5
-1
@@ -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.
|
||||
`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`
|
||||
objects from `build_cpus_aml`) and both VMAware builds still read bare metal, with no opt-in. The
|
||||
|
||||
@@ -90,15 +90,6 @@ index 2c35dd0..2b6a39c 100644
|
||||
#define ICH9_LPC_NB_PIRQS 8 /* PCI A-H */
|
||||
|
||||
#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 {
|
||||
/* D31:F3 SMBus controller */
|
||||
#define TYPE_ICH9_SMB_DEVICE "ICH9-SMB"
|
||||
|
||||
Reference in New Issue
Block a user