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@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
