[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |