ACPI - No MCFG table in OVMF for x86_64?

[kzinti]

I am using the OVMF firmware under QEMU for development. I currently target both x86_64 and armv8 (aarch64). I have decided not to support older hardware and so was looking at using the MCFG table to enumerate PCI devices.

I am enumerating the ACPI tables under the XSDT and I am not seeing any MCFG table for x86_64. But it is there for aarch64. (Same thing with the RSDT.)

In the past I have downloaded pre-built images of OVMF from here, but it appears they aren't available anymore:
https://github.com/tianocore/tianocore. ... /wiki/OVMF

Anyone has experience with this? Specifically getting MCFG to show up in QEMU for x86_64? I likely just need a new OVMF build and/or will have to rebuild it myself. I have no experience with the later and this is something I'd rather avoid if possible.

Thanks!

[Octocontrabass]

There's no MCFG table on machines that don't have PCIe. QEMU's default machine does not have PCIe.

Use "-machine q35" to emulate a machine with PCIe.

[kzinti]

This makes sense. I now see the MCFG table, thank you.

But I do run into another problem now: my UEFI bootloader isn't started anymore, instead I end up in the UEFI shell:

Code: Select all

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
      FS0: Alias(s):F0a65535a:;BLK0:
          PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)
     BLK1: Alias(s):
          PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell>

I am trying to get into the firmware menu without success.

I am using a FAT 32 image, here are my QEMU flags:

Code: Select all

set(QEMU_FLAGS -serial mon:stdio -m 8G -net none -drive format=raw,file=${CMAKE_BINARY_DIR}/rainbow-efi-${ARCH}.img)

if (ARCH STREQUAL "x86_64")
    list(APPEND QEMU_FLAGS -machine q35 -accel kvm -cpu Conroe -smp 4)
elseif (ARCH STREQUAL "aarch64")
    list(APPEND QEMU_FLAGS -machine virt -cpu cortex-a53 -device virtio-gpu-pci)
endif()

[kzinti]

OK I was able to get into the firmware menu by entering "exit" in the shell. Then I was able to change the boot order to pick up my HDD image first.

I'd like to find a way to not have to do this manually each time I reconfigure my workspace...

This seems to be the problem I am running into (specific to Q35 + OVMF):
https://bbs.archlinux.org/viewtopic.php?id=216032

[Octocontrabass]

You should be able to save the boot order to NVRAM and reuse it on subsequent boots. You need a separate copy for each machine.

I'm not sure why the default behavior isn't to boot from disk, though. Maybe it's something that can be set at build time? (I didn't build my copy of OVMF, I got it from a QEMU installer.)

[kzinti]

Yeah it does save to NVRAM and then I am set until I need to reconfigure my project. This happens mostly when I modify my main cmake file. This is because I create a new NVRAM file at configuration time. I might change that to keep the existing file.

It's probably ok for now, but it is annoying.

Thanks for your help!

[Octocontrabass]

I should clarify since it got lost when I was (re)writing my previous post: my copy of OVMF does boot from the disk, with no NVRAM at all. There may be a default boot order you can set when you build OVMF.

...Or maybe that's the default behavior when you don't attach NVRAM? I should try that...

[kzinti]

The OVMF image I use for x86_64 has built-in nvram (which isn't the case for my aarch64 image).

I ended up modifying the boot order and then adding the updated ovmf image to source control. This way it works properly every time.

What is interesting is that if I remove "-machine type=q35" to go back to what I had before, the problem comes back and the boot order is wrong! I suppose the updated NVRAM setting for Q35 doesn't work properly with the default machine (i440fx?).

[kzinti]

It appears to me that my OVMF build has "UEFI shell" as the first boot option. If this wasn't the case, it would just work. It might be something configurable at built time.