[vfio-users] IGD passthrough on UEFI platforms

[Daimon Wang]

Hi Alex,    Is it possible that the UEFI ROM doesn't exist for an IGD? Anyway to check it?    I was booting kernel 4.13 on an 1037U, with the BIOS
default to legacy mode and UEFI turned off. When I turn UEFI on, the IGD just behave abnormal, (e.g. lack of refresh)    I've fix a similar problem on an i3 CPU (lots of refresh , blink), by installing intel-microcode. But that doesn't help on the 1037U.

Regards,Daimon 

    On Thursday, January 4, 2018 3:26 AM, Alex Williamson <alex.williamson at redhat.com> wrote:
 

 On Wed, 3 Jan 2018 17:40:56 +0200
Dmitry Fleytman <dmitry.fleytman at 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 at redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20180109/18357c7c/attachment.htm>