RE: [PATCH 0/4] Prepare bhyve's OVMF for GPU-Passthrough

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