Hi Corvin,
As far as I know, QEMU uses OVMF with bus enumeration enabled. How
does QEMU solve such issues?
Full-time corp Linux staff working on Qemu, KVM and EFI.
- there is no need for EFI to perform a slow scan via PCI bus
operations, resulting in VM-exits, where bhyve can perform all this
in memory, which can result in faster boot.
I didn't measured boot time yet. But I didn't noticed any difference
in boot time.
Ok, thanks.
Is it possible to fix this in bhyve ? Can pass-thru ROMs be mapped
just like mmio BARs are ?
I'm mapping passthru ROMs like MMIO BARs (see my patch for AMD GPUs:
https://reviews.freebsd.org/D27456). There are two issues for GPU
Passthrough to work properly:
1. Linux amdgpu driver needs a ROM for AMD GPUs. Linux assumes that
the ROM is shadowed because it's the primary video card. Shadowing is
normally done by EFI. I don't know if it's possible that bhyve
shadows the ROM.
I don't think so. EFI thinks it has ownership of all RAM except for
the < 1MB reserved area, so bhyve-relocated ROMs could be overwritten by
EFI.
While it's possible for PCI ROM regions to be actual executable RAM in
a hypervisor, I suspect that o/s's wouldn't allow this.
The only other possibility would be for EFI to relocate ROMs even if
BAR allocation was done externally. I'm not sure how complex that would be.
2. It's necessary that the ROM is executed by EFI.
Otherwise, it's impossible to get a display output when no OS driver
is loaded. This means, that you don't have a display output while
inside EFI, a bootloader menu (like grub menu) or while installing an
OS.
Understood.
later,
Peter.
