[vfio-users] Some questions regarding VGA Arbitration, BIOS and UEFI Boot

[Bob Dawes]

I agree with AW's general assessment that you need to decide if it's 
worth your time and risk to hardware in $'s before undertaking any sort 
of bios mod but if your just using the bios in qemu it should be 
relatively safe and potentially incredibly easy. The radeon UEFI GOP 
itself is generic so I think modding is not complex but since qemu / 
vfio / ovmf is a thing of limitless pain avoiding wonder you can 
probably get UEFI boot working in an EFI-only OVMF boot by using your 
card ROM as normal and appending the generic GOP as an option rom with 
the qemu command line addition of (for example):

     -option-rom amd_gop_1.57.0.0.0.efirom

You can get AMD gop option ROMS from the tool at the link below, 
searching on the web (where I just got the link below) or extracting 
them from whatever bios you like.

http://www.win-raid.com/t892f16-AMD-and-Nvidia-GOP-update-No-requests-DIY.html

There's a simple bit of code you can run there to update your current 
bios .. but I just stripped the UEFI part out of my bios with a hex 
editor, and had qemu booting fine with the option-rom approach (and 
failing without) - I use a very recent version of the ovmf efi only 
rom/qemu/linux kernel though and my card is originally UEFI so your 
mileage may well vary. I used the newer 1.59 GOP vs 1.53 GOP in my card 
bios and checked version in the UEFI shell with the 'drivers' command 
then booted windows and re-installed my graphics drivers/ran heaven 
benchmark. It made no difference to anything as far as I could tell so I 
doubt the GOP matters much outside boot/reset.

I do recommend going the UEFI route for radeon guest/IGD on the host (as 
per the wonderful description on AW's blog) as I recently did this and 
had absolutely no trouble at all with 64 bit Win10 guest other than 
needing to use the bleeding edge qemu and kernel (I have skylake 
though). I will post a simple EFI only qemu command line example soon 
but had a few questions and wanted to read some of the upstream boards 
first to check I'm not time wasting/in the wrong place/missing the point 
somewhere. Compared to bare metal I'm seeing slight improvements in min 
frame rates and a reduction in time spent swearing at or fixing Windows 
of over 95%.

Big thanks to all the people that worked on this.

On 23/03/16 07:38, Zir Blazer wrote:
> Great answers, as expected. Some smaller miniquestions/comments followups
>
> ----------------------------
> >> 1) The host using UEFI or legacy BIOS and VGA support is 
> irrelevant.  In an ideal world, maybe this wouldn't be the case, but 
> Xorg wants exclusive access to VGA even though it probably doesn't use 
> it.  Find someone to go fix Xorg.
>
> Since you mentioned that this specific issue is Xorg side, do you 
> think that testing this in Wayland/Weston could be worth a shot? As 
> far that I know, Wayland reuses Xorg GPU Drivers, so I'm not precisely 
> optimistic about this.
>
>
> >>2) Yes, you should probably try secondary graphics passthrough, this 
> typically works for AMD cards and would probably allow you to avoid 
> the whole VGA issue.
>
> Gotcha. So worst case scenario, I can reproduce my current Xen setup.
>
>
> >>3) IGD issues are numerous; dependencies not only on the PCI address 
> of the device in the guest, but also stolen memory configuration, 
> OpRegion access, vBIOS fixups, LPC bridge presence and IDs, and host 
> bridge identification.  Go read the upstream development threads or 
> maybe I'll write a blog post about it some day.
>
> Looks a lot more complex that I thought, since from the xen-devel 
> Mailing List, most of the things that I recall about the IGD 
> Passthrough were about reserving the PCI Address. I suppose that most 
> of that will have to be done anyways for Intel KVMGT/iGVT-g support, 
> which I'm also waiting for.
> Last time I checked a developer mail list was some months ago when 
> there was a proposal for a vGPU API that included some VFIO guys, the 
> Intel guys from iGVT-g, and the nVidia guys for their GRID. A mammoth 
> task to standarize all that, indeed.
>
>
> >>4) romfile= doesn't care about the size of the physical option ROM 
> space on the device.  I've never tried to mod a ROM for UEFI support, 
> in fact, why bother, are you somehow attached to this 5770?  For an 
> investment of $100USD a GTX750 handily beats it, includes UEFI 
> support, and uses less power.  How much is your time worth?
>
> I'm from a third world country, 100 U$D means more for me than for 
> you. And since I'm not employed, I do have free time to tinker with 
> these things (For as long as they don't go above my frustration 
> threshold when I'm not getting results!).
> Getting my loyal 5770 to work with pure UEFI Boot means that I don't 
> have to use the slighty more complicated instructions with VGA 
> Arbitration, and that I would be able to install a guest Windows with 
> UEFI-GPT, so I wouldn't have to reinstall down the road if I get a 
> modern Video Card and have to change the Passthrough method. But since 
> as you stated, I can go the Secondary VGA Passthrough way, this is not 
> precisely critical... Still, it is a good tinkering exercise. However, 
> for someone using an older nVidia Video Card or that wants to do 
> Multiseat, it could be a life savior. It all comes down to how easy it 
> is to mod them - still have to look into that.
> I do plan to upgrade after the release of the next nVidia generation, 
> for as long as money allows to get a high end part. The GeForces 980 
> are around 2 years old and I would feel consumer's guilt if I spend to 
> get one considering than Pascal should be around the corner.
>
>
> And adding a 5)
>
> 5) In pretty much all guides I read about VFIO Passthrough, you have 
> to bind the PCI Device to the vfio-pci Kernel Module. Xen has a Kernel 
> Module named xen-pciback which serves the same purpose. However, there 
> is a BIG difference: xen-pciback works with PCI Address (01:00.0, 
> 01:00.1), while vfio-pci instead uses Vendor:Device ID (1002:68b8, 
> 1002:aa58). As far that I know, this is an issue if you have two 
> identical parts, and want to do Passthrough of one but not the other 
> (Yes, I do have not one, but TWO 5770s, and if I were to upgrade to a 
> LGA 2011-3 platform which has no Intel IGP, I would hit this issue 
> where I would want one for host, other for Passthrough. Not that cash 
> allows that to happen, but I'm dying for a soon-to-come Broadwell-E).
> So, to not make the question longer: Is there a way to supply vfio-pci 
> PCI Address instead of Vendor:Device ID? I think the PCI Address 
> method is better because you don't have the previous issue if there 
> are multiple identical devices. I'm curious about why that format was 
> chosen.
>
>
>
> Thanks for your time. Much appreciated.
>
>
> _______________________________________________
> 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/20160324/9756f16e/attachment.htm>