[vfio-users] UEFI not respecting video output selection

[Ryan A Young]

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 <lersek at 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