Re: [Xen-devel] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Gerd Hoffmann <kraxel@xxxxxxxxxx>]

  Hi,

> 1) The OpRegion MemoryRegion is mapped into system_memory through
> programming of the 0xFC config space register.
>  a) vfio-pci could pick an address to do this as it is realized.
>  b) SeaBIOS/OVMF could program this.
> 
> Discussion: 1.a) Avoids any BIOS dependency, but vfio-pci would need to
> pick an address and mark it as e820 reserved.  I'm not sure how to pick
> that address.

Because of that I'd let the firmware pick the address and program 0xfc
accordingly, i.e. (b).  seabios can simply malloc two pages and be done
with it (any ram allocated by seabios will be tagged as e820 reserved).

> 2) Read-only mappings version of 1)
> 
> Discussion: Really nothing changes from the issues above, just prevents
> any possibility of the guest modifying anything in the host.  Xen
> apparently allows write access to the host page already.

I think read-only is out.  Probably xen allows write access because
guest drivers expect they have write access to the opregion, so the
question is ...

> 3) Copy OpRegion contents into buffer and do either 1) or 2) above.

whenever we give the guest a copy of the host opregion or direct access.

> 4) Copy contents into a guest RAM location, mark it reserved, point to
> it via 0xFC config as scratch register.
>  a) Done by QEMU (vfio-pci)
>  b) Done by SeaBIOS/OVMF
> 
> Discussion: This is the most like real hardware.  4.a) has the usual
> issue of how to pick an address, but the benefit of not requiring BIOS
> changes (simply mark the RAM reserved via existing methods).  4.b) would
> require passing a buffer containing the contents of the OpRegion via
> fw_cfg and letting the BIOS do the setup.  The latter of course requires
> modifying each BIOS for this support.

Maybe we should define the interface as "guest writes 0xfc to pick
address, qemu takes care to place opregion there".  That gives us the
freedom to change the qemu implementation (either copy host opregion or
map the host opregion) without breaking things.

> Of course none of these support hotplug nor really can they since
> reserved memory regions are not dynamic in the architecture.

igd is chipset graphics and therefore not hotpluggable anyway (on
physical hardware), I'd be very surprised if the guest drivers are
prepared to handle hotplug.

> Another thing I notice in this series is the access to PCI config space
> of both the host bridge and the LPC bridge.  This prevents unprivileged
> use cases

lpc bridge is no problem, only pci id fields are copied over and
unprivileged access is allowed for them.

Copying the gfx registers of the host bridge is a problem indeed.

> Should vfio add
> additional device specific regions to expose the config space of these
> other devices?

That is an option.  It is not clear yet which route we have to take
though.  Testing shows that newer linux drivers work fine even without
igd-passthru=on tweaks, whereas older linux kernels and windows drivers
don't work even with this series applied and igd-passthru=on.  I'll go
look at this as soon as I have test hardware (getting some is wip atm).

cheers,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel