RE: [PATCH] OvmfPkg: reserve igd memory by E820

Hi Gerd,

thanks for your reply.

> First, there is no need to communicate memory regions from the
> hypervisor to the guest.  The IGD hardware has registers pointing
> to the opregion and to stolen memory, so the guest can simply
> allocate and initialize memory, then program the registers
> accordingly.  Same procedure you have when initializing IGD on
> physical hardware.

As far as I know, on physical hardware it's done by UEFI. Sadly, the
Intel GOP driver doesn't do it.

> Second, that doesn't belong into OVMF.  Drivers for virtual/emulated
> hardware are fine, but we certainly don't want enter the business of
> maintaining drivers for physical hardware in OVMF.

Understandable.

> An EFI driver in the igd option rom should be able to handle all of
> the above just fine, and for Intel it should also be easy to cover
> differences in hardware generations in the driver.  Bonus points
> for also setting up a GOP for the IGD ;)

I'm already passing the Intel GOP as option rom to my bhyve VM.

> Unfortunately Intel didn't manage it yet to provide an igd option
> rom for virtual machines (or fix their regular driver to also work
> in virtual machines) even though this discussion is ongoing on
> and off for years meanwhile :(

I saw some of this discussions.

> BTW: Do you talk about GVT-d (== build virtual IGD devices with some
> resources of the physical device, roughly comparable to SR-IOV but
> with the igd kernel driver instead of the hardware handling this)?
> Or do you want pci-assign the complete igd device?

Intel has different terms for their GPU passthrough, GVT-d, GVT-g and
GVT-s. I'd like to use GVT-d which means pci-assigning the
complete igd device.

> Lovely.  Intel should fix their broken windows drivers ...
>
> The etc/e820 fw_cfg file can have both 'ram' and 'reserved' entries.
>
> And, yes, adding a 'reserved' entry there for the region which requires
> an identity mapping (to workaround the driver bug) is fine and should
> make sure the region is not used for something else.  Everything else
> should be handled by the igd efi driver / optionrom.

At the moment, my bhyve implementation allocates GSM and OpRegion in
guest memory, copies OpRegion into guest memory, inserts the GSM
and OpRegion addresses into the PCI registers and creates an E820
table.

In order to get the Intel GOP driver working, an additional
PlatformGopPolicy driver is required. I know that the
PlatformGopPolicy driver would never be merged to OVMF because
it's a platform dependent driver for physical hardware. However,
EfiRom can be used to create a proper option rom which includes
the PlatformGopPolicy and the GOP driver.

> Also:  As far I know the stolen memory is only needed at boot, for the
> EFI GOP.  Once the guest OS loaded the native drivers for the IGD the
> stolen memory is not needed / not used any more, and in theory the
> drivers should cope with a stolen memory region not being present just
> fine.

I'd like to use the Intel GOP driver.

> For the opregion:  qemu has, for historical reasons, an (optional and
> disabled by default) etc/igd-opregion fw_cfg file.  It was a quick hack
> which ended up staying.  When a option rom is needed anyway the content
> of the opregion can simply be passed to the guest as part of the option
> rom image.  But if you prefer to use fw_cfg instead you should at least
> use the same hack instead of inventing a new one ...
>
> See also:
>   https://gitlab.com/qemu-project/qemu/-/blob/master/docs/igd-assign.txt
>
> Seabios uses etc/igd-opregion, guest code is here:
> https://gitlab.com/qemu-project/seabios/-/blob/master/src/fw/pciinit.c#L291
> Ideally we'd move that to a proper vgabios too ...

Moving all of this into a proper option rom might be a good idea.
It'll require some work to create some tools which build a proper
rom for each system. However, with this solution there aren't any
hacks neither in the hypervisor nor in OVMF.


Best regards
Corvin


Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075