[vfio-users] UEFI not respecting video output selection

Laszlo Ersek lersek at redhat.com
Thu Jul 28 16:59:23 UTC 2016


On 07/28/16 17:38, Ryan A Young wrote:
> Hi all,
> 
> I have been a happy passthrough camper for two years with my HD 7850,
> a BIOS-only card. I recently upgraded to a GTX 1060 which has
> UEFI-capable firmware. It works great in my VM, but I have an issue
> with the UEFI firmware on the host - it always selects the GTX video
> output on bootup, even though I have the primary video card option set
> to "Onboard." This worked fine for the non-UEFI 7850, but it seems
> this option is being ignored for my new UEFI 1060.
> 
> Of course this causes problems with guest assignment because Linux
> attaches various subsystems to the GTX. Right now I am working around
> this by unplugging the monitor cable from the GTX when I power on the
> system, which coerces the UEFI to not use it. Any ideas?

Sounds like a bug in your platform firmware to me.

Which devices are connected during boot is platform policy, so this is
not a "standards compliance bug" in your platform firmware. But, it lets
the user express a preference, and then it ignores that preference -- a bug.

I suggest looking up your exact platform firmware version (run
"dmidecode -t 0" as root), and then contacting the vendor for an upgrade.

Alternatively, a UEFI application could be written for the following:
- locate all GOP (Graphics Output Protocol) instances,
- identify the one you like and the one you dislike (possibly by PCI
  B/D/F, or by PCI vendor ID / device ID)
- disconnect the latter (if it exists), keep the former (if it exists),
- if the preferred one doesn't exist, look up the PciIo protocol
  interface with the desired characteristics, and connect it recursively
- exit with an error code.

You could then add this UEFI application to your BootOrder as very first
option, before your Linux boot option (shim or grub). (Assuming your
platform firmware allows for such flexibility.) Since the app would
always fail, it would invariably force the platform firmware's boot
manager to continue with the next option in BootOrder.

If your platform fw supports SysPrep#### options, then the above could
be done without Boot#### option / return status abuse.

So it might be possible, but it would be incredibly ugly. (And, it
wouldn't work with Secure Boot enabled, with the "usual" certificates
enrolled, if you are into that.)

You could also experiment with "less than mainstream" UEFI boot loaders
(e.g., rEFInd?) as well; perhaps they allow you to fiddle with this.

In any case, getting the firmware vendor to fix their bug is much
cleaner; I don't think dual graphics is unusual these days.

Thanks
Laszlo




More information about the vfio-users mailing list