On Thu, 30 Jul 2020 at 16:58, Michael S. Tsirkin <m...@redhat.com> wrote: > > On ARM/virt machine type QEMU currently reports an incorrect _UID in > ACPI. > > The particular node in question is the primary PciRoot (PCI0 in ACPI), > which gets assigned PCI0 in ACPI UID and 0 in the > DevicePath. This is due to the _UID assigned to it by build_dsdt in > hw/arm/virt-acpi-build.c Which does not correspond to the primary PCI > identifier given by pcibus_num in hw/pci/pci.c > > 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.) > > A similar bug has been reported on i386, on that architecture it has > been reported to confuse at least macOS which uses ACPI UIDs to build > the DevicePath for NVRAM boot options, while OVMF firmware gets them via > an internal channel through QEMU. When UEFI firmware and ACPI have > different values, this makes the underlying operating system unable to > report its boot option. > > Reported-by: vit9696 <vit9...@protonmail.com> > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > --- > > Peter can you either ack or merge this one pls?
Since you have the x86 one to do anyway, I'll let you take this one. Acked-by: Peter Maydell <peter.mayd...@linaro.org> thanks -- PMM
