[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.

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.


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 redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]