chore: release 1.4.1

docs/ANALYSIS.md

@@ -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)

packaging/vfio-native-kvm-dkms/PKGBUILD

@@ -27,7 +27,7 @@
 pkgname=vfio-native-kvm-dkms
 _pkgbase=vfio-native-kvm
 _kver=7.2.3
-_tag=1.4.0
+_tag=1.4.1
 pkgver=${_kver}
 pkgrel=1
 pkgdesc="KVM modules patched to raise the exceptions the architecture specifies (DKMS, 7.2.x kernels)"

packaging/vfio-native-qemu/PKGBUILD

@@ -7,9 +7,9 @@
 
 pkgname=vfio-native-qemu
 _qver=11.1.2
-_tag=1.4.0
+_tag=1.4.1
 pkgver=${_qver}
-pkgrel=2
+pkgrel=3
 pkgdesc="QEMU ${_qver} with the vfio-native platform-identity patches, in /opt/qemu-native"
 arch=('x86_64')
 url="https://git.archworks.co/sandwich/vfio-native"

packaging/vfio-native/PKGBUILD

@@ -8,7 +8,7 @@
 #   vfio-native-qemu       QEMU 11.1.2 with the platform-identity patches, in /opt
 
 pkgname=vfio-native
-pkgver=1.4.0
+pkgver=1.4.1
 pkgrel=1
 pkgdesc="Present a libvirt guest as a self-consistent physical machine, and tune it"
 arch=('any')

patches/README.md

@@ -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

patches/qemu/03-pci-ids.patch

@@ -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"