I'm sure I asked this before and was expecting AW tehnical response, but instead he said "TL;DR" since it was in a ridiculous long mail with a multitude of other questions. But now I need a response since I plan to do this next week, so I have to try again.
I have readed this numerous times and still think its missing one or two examples to understand it better... http://vfio.blogspot.com.ar/2014/08/whats-deal-with-vga-arbitration.html As far that I managed to understand, the VGA Arbitration is an issue when you have two or more Devices that wants to use the legacy VGA protocol (Including both host and VM passthroughed Devices), which is a phase that usually only last until the OS loads the GPU Drivers and disables it. This is fine. However, there are some thing that are missing... 1) My current setup includes a Haswell platform with the Intel IGP, and a Radeon 5770 from before UEFI GOP became available, so it is legacy VBIOS only. I understand that OVMF allows you to load a Video Card PCI Option ROM with UEFI GOP at VM POST time, in which case, you can see OVMF POSTing in the Monitor attached to the passthroughed Video Card, and that is called Primary VGA Passthrough. SeaBIOS can do the same loading a legacy VBIOS PCI Option ROM during POST. This phase last during the boot process until the OS GPU Drivers takes over, and at that point, both BIOS/UEFI Boot converge since the Drivers should disable VGA. The advantage of the pure UEFI Boot method is that VGA is not used during boot, so you don't count it at any point for VGA Arbitration purposes. However, this should apply for UEFI Boot in the host, too. Since I do passthrough of the Radeon 5770 to a Windows VM, I will have to use SeaBIOS with legacy VBIOS and VGA for booting if doing Primary VGA Passthrough, but the host GPU has no need for VGA at all. The Intel IGP has available UEFI GOP support (At least since Ivy Bridge I think, but Haswell absolutely has it since that's my platform and I can confirm it), so I can do a pure UEFI Boot with no CSM for the host. VGA should not be used at all for the Intel IGP, which means that I have the legacy VGA protocol exclusively for the Radeon 5770 VM, so I should be able to create it using SeaBIOS and load the Video Card legacy VBIOS, and expect it to do Primary VGA Passthrough without having to deal with VGA Arbitration issues. Is this correct? What makes me doubt is that you mention that the mechanism for Intel IGP Drivers to opt out of VGA Arbitration seems to be broken, but you blogged that before OVMF took over, and make no mention regardless if that applies to host BIOS Boot with Intel IGP, or BOTH BIOS and UEFI Boot. This is important to me since I have a Radeon 5770 from before they started to incorporate UEFI GOP support, so for Primary VGA Passthrough I have to use SeaBIOS. 2) What about Secondary VGA Passthrough? In the case of my current setup using Xen, the VM POST in a SDL window in the host screen, then switchs to the Monitor attached to the VM when Windows begins loading. This means that VGA isn't used either, since no VBIOS is loaded at all, through that also means that the Video Card is useless without the OS Drivers. So, can VFIO also do Secondary VGA Passthrough? I barely recall seeing it mentioned. Truth be told, for as long as when we reach the convengence point after the OS loads the Drivers everything works as intended, how I get there seems like a detail that doesn't really matters. If I can use an emulated VGA for VM POST and boot, then switch to the passthroughed Video Card, I don't see it as a con of Secondary VGA Passthrough and would say that it is a slighty easier method. The main advantage being that it should be universal regardless if the host is doing BIOS or UEFI Boot, there is another VM using a passthroughed Video Card using legacy VBIOS, etc, since it simply doesn't care for those details. 3) What are the issues with Intel IGP Passthrough and VFIO? I'm not intending to do it since it would be worse than my Radeon 5770, but I'm curious. If I recall correctly, there were issues with it on Xen that required patches, since it seems that either it or the Drivers are expecting for the IGP to sit on PCI Address 00:02.0, so when doing IGP Passthrough, that address got reserved for it. Isn't possible to workaround this currently in standalone QEMU? Can't see why you wouldn't be able to use -nodefaults, then plug in -device vfio-pci,bus=pcie.0,addr=02.0,host=00:02.0, or something like that. If it requires a PCIe Root Complex and can't be workarounded for the i440FX PCI Host Bridge, then maybe it works on Q35. I was intending to try this when I deploy standalone QEMU, but I would like to hear the technical explanation. 4) What should be the success chance of modding a VBIOS to add UEFI GOP support and use it for OVMF? At some point I was intending to do that mod for my Radeon 5770, but after tons of googling, I found other users claiming that it had a peculiar issue: The ROM was too small. It is a 64 KiB Flash ROM, while the resulting binary after performing the mod handily surpassed that size. But I think that I saw smaller cards like Radeons 5450 successfully modded adding UEFI GOP, through the guys that performed it were interesed in using them for MAC platforms or Windows 8 Fast Boot, no one was interesed in OVMF UEFI Boot. Now, I know that QEMU supports a romfile= parameter that would allow me to replace the default PCI Option ROM with something else. Would it be possible to load a bigger file? Without the ROM size constrains, the UEFI GOP modding could actually be useful. Heck, it would be absolutely wonderful if someone can develop a way to consistently perform such mod on a given VBIOS, since it would be THE ABSOLUTE SAVIOR of all the legacy Video Cards users, stomping VGA Arbitration and anything else along the way. Heck, you don't even have to actually flash the ROM to try if it works or not. This sounds at least wonderful on paper, but would like to know if someone tried, succeded, or believes that being able to load a ROM is as good as I think it is. I expect to get AW to reply this time, heh. Seriously, I can't make wall of texts smaller than this since i always try to explain context and my thoughs. _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
