I just updated my BIOS to a version released last week and this bug is still present. Maybe I will email ASRock about it.
In any case, Samuel has given me a workaround; no custom UEFI applications needed. ;-) Ryan On Thu, Jul 28, 2016 at 11:59 AM, Laszlo Ersek <ler...@redhat.com> wrote: > 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 > -- - Ryan _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
