On Wed, 3 Jan 2018 17:40:56 +0200 Dmitry Fleytman <dmitry.fleyt...@gmail.com> wrote: > > Thanks for your suggestion. We were able to boot Linux with IGD assignment > successfully. > > One more question - what about UEFI only OSes, like MacOS? > > As far as I understand, such a configuration is not supported. Am I right? > What are the missing parts required to support UEFI VM with IGD passthrough?
Correct, unsupported. Missing part #1 are the fw_cfg interfaces between QEMU and SeaBIOS. One provides SeaBIOS with OpRegion data that it stuffs into reserved memory and writes back the location to the device. The other tells SeaBIOS how much memory to reserve for stolen memory and has it write it back to the device. The latter of these enables a hack in QEMU which traps graphics translation updates to the device and redirects them to this guest stolen memory rather than the host's. This is the most fragile piece of IGD assignment and really relies on the device barely needing to use stolen memory. It's unclear where Intel is headed with stolen memory and their hardware designers casually change the interface with every generation, so it's possible drivers will depend more on this in the future and that our hack will not be compatible with new hardware. Intel would rather that host stolen memory be directly mapped to the VM, but this is also a pretty ugly thing to do. In general there's a lot of uncertainty here, which makes proposing an already slightly hacky interface to something like UEFI even more undesirable. Missing part #2, where do you get a UEFI compatible IGD ROM? Does it work? In my limited experience, the IGD UEFI ROM is built into the firmware rather than being exposed as a PCI option ROM, so how QEMU gets it to expose to the VM isn't clear. Exercise for the user? The core problem with IGD assignment is that IGD is partially exposed as a PCI device, but it is not self contained within that PCI device like other discrete graphics. Graphics memory lives somewhere in reserved memory and the address of that memory is latched into the hardware by the host firmware at boot, in-memory descriptors of the output configuration live elsewhere in reserved memory, other PCI devices, like the host bridge and LPC bridge, are used to manage other aspects of the IGD device. And to top off that mess, it's a moving target that Intel only occasionally gets interested in supporting. Thanks, Alex _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
