Re: [edk2-devel] [PATCH v2 1/2] OvmfPkg/IntelGvtGopDxe: Intel GVT-g GOP Implementation.

[kraxel@redhat.com]

  Hi,

> operations but handle the common logic. In this opregion case, QEMU and
> seabios only copies the raw data, but the contents are left to gvt to fill
> so that gvt could fill different data in different cases.

Yes, gvt could do that.

The big question is: does that actually happen?  When looking at
drivers/gpu/drm/i915/gvt/opregion.c it seems the opregion is pretty
static.

Are there plausible reasons for that capability being needed in the
future?

> Otherwise any change requires SEABIOS update, instead of dyncamilly
> filled by gvt.

That clearly isn't an option.

> One benefit OVMF overcomes SEABIOS is that IntelGvtGopDxe can be loaded
> as a standalone driver.

Well, seabios allows standalone drivers too.  It's called vgabios ;)

> So it maybe possible that in OVMF case, both gvt and
> IntelGvtGopDxe can act part of Intel vGPU virtualization component. However
> the behavior of gvt+seabios and gvt+ovmf will be inconsistent.

Well, in case the opregion is not static there is still the option to
use the pci rom bar instead of fw_cfg to deliver the opregion content
to the guest.

> May need
> update gvt logic so that if IntelGvtGopDxe generate opregion, gvt can still
> update it before any opregion consumer using it.

Hmm.  Can gvt trap pci config space writes?  IIRC pci config space is
simply yet another vfio region, so that should be possible.  gvt could
update the opregion then when the firmware updates the opregion address.

If that actually works there is little reason for IntelGvtGopDxe (and
seabios) to fill the opregion in the first place though.  We could
change the opregion initialization protocol to something like this:

  (1) firmware allocates memory for the opregion
  (2) firmware fills signature and size
  (3) firmware writes opregion address to pci config space
  (4) gvt goes fill opregion at the given address in guest memory.

Maybe it would be better to reserve a paravirtual mmio register for that
purpose to make the whole thing a bit more robust.

> Then, loading fw_cfg can be
> dropped without preventing guest OS driver find it.

I guess we have to keep that for a while for backward compatibility
reasons.

take care,
  Gerd