af1b80ae56
macOS uses ACPI UIDs to build the DevicePath for NVRAM boot options, while OVMF firmware gets them via an internal channel through QEMU. Due to a bug in QEMU ACPI currently UEFI firmware and ACPI have different values, and this makes the underlying operating system unable to report its boot option. The particular node in question is the primary PciRoot (PCI0 in ACPI), which for some reason gets assigned 1 in ACPI UID and 0 in the DevicePath. This is due to the _UID assigned to it by build_dsdt in hw/i386/acpi-build.c Which does not correspond to the primary PCI identifier given by pcibus_num in hw/pci/pci.c Reference with the device paths, OVMF startup logs, and ACPI table dumps (SysReport): https://github.com/acidanthera/bugtracker/issues/1050 In UEFI v2.8, section "10.4.2 Rules with ACPI _HID and _UID" ends with the paragraph, Root PCI bridges will use the plug and play ID of PNP0A03, This will be stored in the ACPI Device Path _HID field, or in the Expanded ACPI Device Path _CID field to match the ACPI name space. The _UID in the ACPI Device Path structure must match the _UID in the ACPI name space. (See especially the last sentence.) Considering *extra* root bridges / root buses (with bus number > 0), QEMU's ACPI generator actually does the right thing; since QEMU commit |
||
---|---|---|
.. | ||
kvm | ||
xen | ||
acpi-build.c | ||
acpi-build.h | ||
acpi-common.c | ||
acpi-common.h | ||
amd_iommu.c | ||
amd_iommu.h | ||
e820_memory_layout.c | ||
e820_memory_layout.h | ||
fw_cfg.c | ||
fw_cfg.h | ||
intel_iommu_internal.h | ||
intel_iommu.c | ||
Kconfig | ||
kvmvapic.c | ||
meson.build | ||
microvm.c | ||
multiboot.c | ||
multiboot.h | ||
pc_piix.c | ||
pc_q35.c | ||
pc_sysfw.c | ||
pc.c | ||
port92.c | ||
trace-events | ||
trace.h | ||
vmmouse.c | ||
vmport.c | ||
x86-iommu-stub.c | ||
x86-iommu.c | ||
x86.c |