<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px"><div id="yui_3_16_0_ym19_1_1515467136054_34128"><span>Hi Alex,</span></div><div id="yui_3_16_0_ym19_1_1515467136054_34128" dir="ltr"><span id="yui_3_16_0_ym19_1_1515467136054_34309"> Is it possible that the UEFI ROM doesn't exist for an IGD? Anyway to check it?</span></div><div id="yui_3_16_0_ym19_1_1515467136054_34128" dir="ltr"><span id="yui_3_16_0_ym19_1_1515467136054_34437"> I was booting kernel 4.13 on an 1037U, with the BIOS<br></span></div><div id="yui_3_16_0_ym19_1_1515467136054_34128" dir="ltr"><span id="yui_3_16_0_ym19_1_1515467136054_34416">default to legacy mode and UEFI turned off. When I turn UEFI on, the IGD just behave abnormal, (e.g. lack of refresh)</span></div><div id="yui_3_16_0_ym19_1_1515467136054_34128" dir="ltr"><span id="yui_3_16_0_ym19_1_1515467136054_34713"> 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.<br></span></div><div id="yui_3_16_0_ym19_1_1515467136054_34128" dir="ltr"><span><br></span></div><div id="yui_3_16_0_ym19_1_1515467136054_34128" dir="ltr"><span>Regards,</span></div><div id="yui_3_16_0_ym19_1_1515467136054_34128" dir="ltr"><span>Daimon</span></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Thursday, January 4, 2018 3:26 AM, Alex Williamson <alex.williamson@redhat.com> wrote:<br></font></div> <br><br> <div class="y_msg_container"><div dir="ltr">On Wed, 3 Jan 2018 17:40:56 +0200<br clear="none">Dmitry Fleytman <<a shape="rect" ymailto="mailto:dmitry.fleytman@gmail.com" href="mailto:dmitry.fleytman@gmail.com">dmitry.fleytman@gmail.com</a>> wrote:<br clear="none">> <br clear="none">> Thanks for your suggestion. We were able to boot Linux with IGD assignment successfully.<br clear="none">> <br clear="none">> One more question - what about UEFI only OSes, like MacOS?<br clear="none">> <br clear="none">> As far as I understand, such a configuration is not supported. Am I right?<br clear="none">> What are the missing parts required to support UEFI VM with IGD passthrough?<br clear="none"><br clear="none">Correct, unsupported. Missing part #1 are the fw_cfg interfaces<br clear="none">between QEMU and SeaBIOS. One provides SeaBIOS with OpRegion data that<br clear="none">it stuffs into reserved memory and writes back the location to the<br clear="none">device. The other tells SeaBIOS how much memory to reserve for stolen<br clear="none">memory and has it write it back to the device.<br clear="none"><br clear="none">The latter of these enables a hack in QEMU which traps graphics<br clear="none">translation updates to the device and redirects them to this guest<br clear="none">stolen memory rather than the host's. This is the most fragile piece of<br clear="none">IGD assignment and really relies on the device barely needing to use<br clear="none">stolen memory. It's unclear where Intel is headed with stolen memory<br clear="none">and their hardware designers casually change the interface with every<br clear="none">generation, so it's possible drivers will depend more on this in the<br clear="none">future and that our hack will not be compatible with new hardware.<br clear="none">Intel would rather that host stolen memory be directly mapped to the VM,<br clear="none">but this is also a pretty ugly thing to do. In general there's a lot of<br clear="none">uncertainty here, which makes proposing an already slightly hacky<br clear="none">interface to something like UEFI even more undesirable.<br clear="none"><br clear="none">Missing part #2, where do you get a UEFI compatible IGD ROM? Does it<br clear="none">work? In my limited experience, the IGD UEFI ROM is built into the<br clear="none">firmware rather than being exposed as a PCI option ROM, so how QEMU<br clear="none">gets it to expose to the VM isn't clear. Exercise for the user?<br clear="none"><br clear="none">The core problem with IGD assignment is that IGD is partially exposed as<br clear="none">a PCI device, but it is not self contained within that PCI device like<br clear="none">other discrete graphics. Graphics memory lives somewhere in reserved<br clear="none">memory and the address of that memory is latched into the hardware by<br clear="none">the host firmware at boot, in-memory descriptors of the output<br clear="none">configuration live elsewhere in reserved memory, other PCI devices,<br clear="none">like the host bridge and LPC bridge, are used to manage other aspects<br clear="none">of the IGD device. And to top off that mess, it's a moving target that<br clear="none">Intel only occasionally gets interested in supporting. Thanks,<div class="yqt5554427958" id="yqtfd93914"><br clear="none"><br clear="none">Alex<br clear="none"><br clear="none">_______________________________________________<br clear="none">vfio-users mailing list<br clear="none"><a shape="rect" ymailto="mailto:vfio-users@redhat.com" href="mailto:vfio-users@redhat.com">vfio-users@redhat.com</a><br clear="none"><a shape="rect" href="https://www.redhat.com/mailman/listinfo/vfio-users" target="_blank">https://www.redhat.com/mailman/listinfo/vfio-users</a><br clear="none"></div></div><br><br></div> </div> </div> </div></div></body></html>