[edk2-devel] [PATCH] OvmfPkg: reserve igd memory by E820

[Gerd Hoffmann]

  Hi,

> > 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.

Where does the intel gop driver come from?  Extracted from host
firmware?

> > 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.

Ah, ok, didn't notice the subtile differences with the small letter at
the end.  GVT-d + GVT-g is clear then.  What is GVT-s ?

> > 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.

Ideally the guest would allocate and initialize this all itself.
That is hard for the GSM though when it requires an identity
mapping.

Having the guest check whenever the GSM register points to reserved
memory and if so use it instead of allocating memory should work I
think.

> > 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.

Once we have the code for vgabios and PlatformGopPolicy we can roll them
with the intelgop driver into a rom image with EfiRom.  Ideally also add
opregion content to the rom somehow.

> However, with this solution there aren't any
> hacks neither in the hypervisor nor in OVMF.

Yep, that's the main point of the approach.  Make it self-contained and
not depend on specific behavior/support in hypervisor and/or firmware.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88421): https://edk2.groups.io/g/devel/message/88421
Mute This Topic: https://groups.io/mt/90236075/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-