On Wed, 2015-03-25 at 16:00 +0000, Gordan Bobic wrote: > On 2015-03-25 15:46, Alex Williamson wrote: > > On Wed, 2015-03-25 at 16:25 +0100, Laszlo Ersek wrote: > >> On 03/25/15 11:12, Gordan Bobic wrote: > >> > Hi, > >> > > >> > I'm trying to solve what should be a relatively simple problem > >> > of side-loading a GPU VBIOS but I am running into an unexpected > >> > problem. > >> > > >> > The setup is a laptop with Optimus setup (Intel primary + Nvidia > >> > headless), and I want to pass the headless Nvidia GPU to the KVM > >> > virtual machine. Unfortunately, the GPU appears to be > >> > uninitialized in the VM, judging by the GPU-Z symptoms. > >> > > >> > The VBIOS in question isn't on an EEPROM attached to the GPU, it > >> > is instead in the main system BIOS payload (which actually contains > >> > 3 Nvidia BIOS-es, presumably for different compatible GPUs). I > >> > extracted all the BIOS blobs using PhoenixTool and deduced the > >> > correct one, but the blob in question appears to have the EFI > >> > header missing - which means it looks much like a legacy BIOS, > >> > rather than an EFI one (type 0 header is there, but type 3 > >> > header is not. But the crypto certs are in fact there in the > >> > BIOS payload, which indicates it is an EFI BIOS after all, > >> > only with the type 3 header stripped out. > >> > >> You can use the EfiRom utility from the edk2 git tree, with the > >> "--dump" > >> option, to "Dump the headers of an existing option ROM image". > >> > >> I don't know of any utility offhand that extracts images from > >> expansion > >> ROMs (splitting off the expansion ROM header and the PCI Data > >> Structure > >> etc). > >> > >> > Is the EFI header as described (usually 1KB on Nvidia Kepler > >> > BIOS-es and 1.5KB on Nvidia Maxwell BIOS-es) only applicable > >> > to discrete EFI BIOS-es? Is it handled differently if the > >> > GPU BIOS is integrated into the main system BIOS payload? > >> > >> Normally the UEFI driver is built as a UEFI executable. The EfiRom > >> utility (or another equivalent tool) is used to build it (possibly > >> together with other such executables) into an expansion ROM. This > >> procedure formats the "PCI Data Structure" and "PCI Expansion ROM > >> Header" structs into the output file, as specified in the "PCI (TM) > >> Firmware Specification Revision 3.1". > >> > >> > If so, is there a method for incorporating the GPU firmware > >> > I have extracted into the OVMF core instead of side-loading > >> > it? > >> > >> Yes, there is. (Well, assuming that whatever you extracted is indeed a > >> UEFI binary.) > >> > >> Method #1 is to place the binary somewhere appropriate in the edk2 > >> tree, > >> write an INF file for it, include the INF file in > >> "OvmfPkg/OvmfPkgX64.fdf", and rebuild OVMF. Since this is going to be > >> a > >> binary-only module, you can refer to the following examples: > >> - FatBinPkg/EnhancedFatDxe/Fat.inf > >> - EdkShellBinPkg/FullShell/FullShell.inf > >> > >> Method #2 is similar, except you don't need to write an INF file. > >> Search > >> the same FDF file for "Intel3.5/EFIX64/E3507X2.EFI". > >> > >> Method #3 is to prepare a disk image with a FAT32 partition. Then copy > >> the extracted binary to this filesystem, using mtools or guestfish. > >> During OVMF boot, enter the UEFI shell, and load the driver binary > >> with > >> the "load" command from this filesystem. (This should also connect the > >> driver to matching devices at once.) > >> > >> Hm, I'm just noticing method #4: the UEFI shell has a command called > >> "loadpcirom", which "Loads a UEFI driver from a file in the format of > >> a > >> PCI Option ROM". > > > > That's really cool that there are so many ways to do it, but IMHO the > > most maintenance-free solution seems like it would be to stuff that > > UEFI > > binary into a PCI option ROM format and expose it to the VM as if the > > GPU had a PCI option ROM, using the romfile= parameter (or <rom > > file=''/> in libvirt). Then you don't need a custom OVMF build, nor do > > you need to do any prep work to pre-load the UEFI driver into the EFI > > partition. Thanks, > > That was the first thing I tried, but I'm finding it difficult to > spot from the OVMF debug log to even tell if it is being loaded > and executed, let alone of it works.
If the ROM doesn't start with AA55, then it's not a valid PCI option ROM and won't be processed. If you're running a version of OVMF without CSM support and the ROM doesn't include a valid type 3 header, then it will not be processed, regardless of whether you believe it's actually a UEFI payload. What you have in the other reply looks like a legacy BIOS, and it very well may work as such, but it's going to require the CSM and likely make callbacks that require VGA support, which is what I expect you're trying to avoid by using OVMF. If the blob you suspect as being a raw UEFI binary (I'm not as hopeful as you and Laszlo seem to be) can be used as a ROM, it would at least need to be wrapped in a PCI option ROM header. Thanks, Alex ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
