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

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.