Hi Peter, thank you for your feedback,
> While it's now possible to allow EFI to scan/assign PCI BARs, I'd like to > avoid it if possible for 2 reasons: > - assignment policy can stay in bhyve, such as whether to locate 64-bit > BARs in the 32-bit region which EFI didn't (doesn't?) allow. Bugs or > corner-cases can be fixed in bhyve without requiring a modification to > upstream EFI. As far as I know, QEMU uses OVMF with bus enumeration enabled. How does QEMU solve such issues? > - 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. > Your patch description states: > > For Linux guests, AMD GPUs require that their PCI ROM is processed by UEFI. > > 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. 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. Best regards Corvin Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075
