Very hacky solution for Windows guest

[arne-claeys]

Dear Mr Coulter

First of all, thanks a lot for your research. In the meantime I have managed to get GPU passthrough (of my muxless NVIDIA GTX 950M) on a Windows guest working as well. At the moment the solution is very hacky, but perhaps it could be useful.

To this end I have hard coded the VROM dump in the OVMF image by patching OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c fwcfg_patch.txt

The VROM is read from a header file and copied to a RuntimePool to make sure it remains persistent after the OS has loaded. In the following part of the code a new ACPI table is defined that first defines an OperationRegion that points to the VROM image. At the end a slightly modified version of your ACPI table, in which I pasted a decompiled version of the ROM call from the SSDT of my laptop, is appended to the rest of the table. The RVBS variable should be set to the actual length of the VROM dump.

ssdt.asl

As currently I don't have sufficient time to figure out a more elegant solution, the following was done to compile this table.

• force compiling the table using iasl -f ssdt.asl The force option is necessary as the OperationRegion is not included in the ASL, but in the preceding part of the ACPI table that was defined in QemuFwCfgAcpi.c.
• using the following script to drop the header of the table and create a hex dump in vrom_table.h buildtable.txt

In my case this made the Error 43 finally disappear. I hope this could be of any help.

Kind regards Arne

[KenMasters20XX]

Alright, had some other stuff to figure out. But yeah, nouveau works just as well as the NVIDIA proprietary driver. Didn't even set up the config, just blacklisted the other drivers, and restarted the display manager. Obviously the nouveau driver has graphical performance issues compared to the NVIDIA proprietary driver.

Again, this is using an up to date Arch Linux guest, with kernel 4.19.5.

EDIT: And yes, I've tested playing games like 'Human: Fall Flat' on both drivers. So GPU acceleration does indeed work.

EDIT2: This required no special configuration to get working. Not even any xorg.confs. I might mention that I went did try a crazy idea the other day. I attempted to get it working in a nested VM with PCI Passthrough. So I ran a Windows VM in the Linux VM to see if that'd do it, but as I thought, it did not work and got the blasted error 43 again.

Wow, this is amazing to hear.

If possible can you post your entire configuration for QEMU? Any relevant kernel patches? My previous setup was with Arch host on 4.18 using Ubuntu 18.04 guests. I'd be willing to completely duplicate your setup as I feel having a graphically accelerated Linux guest could allow me to at least have some confidence in getting the Windows drivers working.

[KenMasters20XX]

Very interesting. Thanks for sharing. Have you tried using a recent kernel in your guest vm? It might also be worth taking a closer look at the kernel panic. Maybe using a serial device or by dumping it. Maybe if you're lucky there may have been enough time for stuff to get written into your syslog.

If I can find the time, I'll try to do it with a Fedora guest and see if it makes any difference. But I'm really short on time. I have to send my notebook back in a week if I don't want to keep it. For now my priorities are getting rid of error 43 in any way no matter how hacky so that I know it can be done on my device.

From what other people reported the GPU works fine in a Linux guest vm on the Aero 15X. Maybe @Verequies can share some details like which distro and kernel version he used and if he actually used nouveau drivers and tested GPU acceleration. Kernel parameters would also be interesting.

I used a stock Ubuntu 18.04 installation as the guest in an Arch host running 4.18 or 4.19.

I never got around to debugging the problem since I wasn't entirely sure if the card was properly passed through to begin with. It initially seemed like a problem with BAR mapping that might be related to my configuration rather than anything else. Was fairly uncertain as to where the actual problem might lie - but since @Verequies has succeeded in getting his 1060 passed through and working, then that tells me it is indeed possible to get this to work - it's just a matter of getting the Windows driver to work.

Getting rid of Code 43 would be fantastic since there doesn't seem to be any other viable path to getting Windows guests graphically accelerated working in the near future.

[Verequies]

@KenMasters20XX I'll help you set yours up to the point mine is if you want to private chat somewhere, I'm using a bunch of scripts I created myself and I don't particularly want to release them into the wild yet as they are a tad unfinished.

In other news, I patched QEMU to disable hotplug on the PCIe slots, well advertise the capability, and while it didn't work, it is nice to not have all those hardware devices coming up in the eject menu. Have also been messing around with the ACPI code, but haven't really made any real progress, so again any help is welcome.

EDIT: Nope, no kernel patches required. Using the default Arch Linux kernel.

[KenMasters20XX]

@KenMasters20XX I'll help you set yours up to the point mine is if you want to private chat somewhere, I'm using a bunch of scripts I created myself and I don't particularly want to release them into the wild yet as they are a tad unfinished.

In other news, I patched QEMU to disable hotplug on the PCIe slots, well advertise the capability, and while it didn't work, it is nice to not have all those hardware devices coming up in the eject menu. Have also been messing around with the ACPI code, but haven't really made any real progress, so again any help is welcome.

EDIT: Nope, no kernel patches required. Using the default Arch Linux kernel.

Yes, any help replicating your current setup would be greatly appreciated. I initially started the process of working on the ACPI tables but without being sure what the problem was, it was difficult to really drill down. With Linux guest working, that would be a huge help in sorting out the issues.

I've setup a Discord server that you can join and we can private chat there if you like (or anywhere really): https://discord.gg/qF5eHKJ

Over there you'll see me as DocDoom (server owner), just shoot me a PM and we can discuss!

Again, thanks for the help!

[T-vK]

@Verequies I have not been able to pass the thunderbolt controller through to the vm so far. I only managed to pass the eGPU itself to the vm. (It's a normal GTX 970 desktop GPU btw.) But I'm getting error 43. The only difference I can see so far (compared to passing the dGPU) is that I didn't have to manually install the Nvidia driver in order for the device to be recognized for what it is in the device manager.

The good news however is that I can keep the notebook that I have until February for further testing.

Since I'm not able to get this ovmf patch to work on Fedora, I'm also very interested in getting this to work on Arch. So I'm very interested in your scripts.

[brandsimon]

@Ashymad Can you please re-upload the files for your PKGBUILD?

[Ashymad]

Done, I've added them to the gist. I've also rebased the PKGBUILD on the newest upstream version.

[brandsimon]

@Ashymad Thank you very much. Sadly, it does not work, I get the following error:

[    8.311285] NVRM: failed to copy vbios to system memory.
[    8.311640] NVRM: RmInitAdapter failed! (0x30:0xffff:650)
[    8.311943] NVRM: rm_init_adapter failed for device bearing minor number 0

I use a arch linux guest to test the setup. (Thinkpad P51 with M1200) I know, that PCI Passthrough works, because when I patch the nvidia driver with this patch, everything is working. (CUDA and 3D via bumblebee with a gvt-g passthrough)

I use this command:

/usr/bin/qemu-system-x86_64 -bios /home/simon/tmp/ovmf_all/other/OVMF_CODE.fd -L ovmf64/ -enable-kvm -M q35 -cpu host,kvm=off,hv_time,hv_vendor_id=nullzwei -smp 4,sockets=1,cores=4,threads=1 -m 16384  -name Tensorflow -rtc base=localtime  -net nic -net user,hostfwd=tcp::22221-:22222 -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,romfile=/home/simon/vms/arch/qemu/vbios_10de_13b6.rom -drive file=/home/simon/vms/arch/arch-devel.qcow2,id=win,format=qcow2,if=none -device ide-hd,bus=ide.0,drive=win  -device nec-usb-xhci,id=usb -device usb-host,vendorid=0x24c6,productid=0x5d04,id=hostdev0,bus=usb.0 -device usb-host,vendorid=0x04d9,productid=0xfa58,id=hostdev1,bus=usb.0  -boot c

Is there an easy way to debug this?

[ghostface]

I have the impression that nobody had success with getting rid of Error 43 using the PKGBUILDs in this thread to compile the patched OVMF image?

[jmandawg]

Tried the PKGBUILD from @Ashymad but still have the Error 43 on the OverPowered laptop from walmart with 1060 GTX.

Also the PKGBUILD also failed the checksum for the nvidia diff file, but i just forced it to skip the check sum.

[ghostface]

I am guessing a lot of people skipped over this part "The RVBS variable should be set to the actual length of the VROM dump." @ ssdt.asl in the original instructions when using the PKGBUILD script.

Gonna give this another try now...

[brandsimon]

@ghostface No, this is happening in the PKGBUILD. sed -i "s/103936/$rom_len/g" ssdt.asl

[T-vK]

Unfortunately, I have still not been able to get this patch built on Fedora. But I was just wondering, shouldn't it be possible and not too difficult to change the source code so that it reads a rom file from disk instead having it hardcoded inside a header file? It's probably more complicated than I think, but in my head it goes something like this: User sets environment variable OVMF_VBIOS_OVERRIDE="/home/me/vbios.rom". Then the ovmf code goes:

char* vbiosFilename = getenv("OVMF_VBIOS_OVERRIDE");
if (vbiosFilename != NULL) {
    FILE *f = fopen(vbiosFilename, "rb");
    unsigned char buffer[1234];
    fread(buffer,sizeof(buffer),1,f);

    // and finally copy the read data to the RuntimePool and all that magic stuff

}

Unfortunately I'm not a C programmer, so I can't really do much. But I'd imagine if someone would change the code accordingly there is a good chance we could get the TianoCore/EDK II developers to implement this upstream, so that we would automatically get decent support for all Linux distros. It would probably make sense to talk to them on their mailing list.

[KenMasters20XX]

I have the impression that nobody had success with getting rid of Error 43 using the PKGBUILDs in this thread to compile the patched OVMF image?

For my build, I've confirmed that the OVMF image was built correctly and that the ROM is exactly the same in the Windows guest as it is on the host. So I suspect the Code 43 issues for mobile Pascal cards (10xx) is not likely due to user error patching in the ROM.

[ghost]

I currently been working on a MSI GS63VR Stealth Pro for the past week now trying to get a GPU passthrough. Thought I'd share how far I've got

My specs:

Host: GS63VR 7RF REV:1.0 Kernel: 4.20.6-arch1-1-ARCH CPU: Intel i7-7700HQ (8) @ 3.800GHz GPU: NVIDIA GeForce GTX 1060 Mobile GPU: Intel HD Graphics 630

lspci -nnk

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106M [GeForce GTX 1060 Mobile [10de:1c20] (rev a1) Kernel driver in use: vfio-pci Kernel modules: nouveau, nvidia_drm, nvidia

/etc/modprobe.d/blacklist.conf

blacklist nouveau blacklist nvidia

/etc/modprobe.d/vfio.conf

options vfio-pci ids=10de:1c20 options kvm ignore_msrs=1

/etc/mkinitcpio.conf

MODULES=(ext4 tun kvmgt vfio_pci vfio vfio_iommu_type1 vfio_virqfd) FILES=(/etc/modprobe.d/vfio.conf /etc/modprobe.d/blacklist.conf)

grub

GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX intel_iommu=on iommu=pt vfio-pci.ids=10de:1c20"

I'm pretty sure the vfio-pci settings helped fixed the Error 43 code I was getting earlier. Here's the configurations i'm trying with virt-manager: (I attached the GPU driver in the settings)

Windows 7 (Ultimate)

 KVM x86_64
 Emulator: /usr/bin/qemu-system-x86_64
 Chipset: Q35
 Firmware: BIOS

Device Manager > Display Adapters > VGA Display Adapter (with a caution symbol)

This device cannot start (Code 10)

I still have yet to try booting windows 7 in UEFI mode, currently haven't figured that out yet so I decided to try windows10

Windows 10

 KVM x86_64
 Emulator: /usr/bin/qemu-system-x86_64
 Chipset Q35 (and i440FX)
 Firmware UEFI x86_64: /usr/share/ovmf/x64/OVMF_CODE.fd

Device Manager > Display Adapters > Microsoft Basic Display (with a caution symbol)

This device is not working proper because Windows cannot load the drivers required for this device. (Code 31)

When I try to install the geforce experience drivers on both Windows10 & 7, I can hear the fan spinning. then I get this error: Installation can't continue This NVIDIA graphics driver is not compatible with this version of Windows.

Then the fan stops. So I think I was able to get the gpu attached but the driver is still not getting detected (error 31) and the gforce installer says its not compatible with this version of windows -- well that's my progress so far. i'm gonna keep trying though lol

---

EDIT* Managed to get a successful GPU pass-through to an external monitor w/ usb keyboard and usb mouse -- on an Ubuntu image; sudo lshw -C video on the VM says it has detected the Nvidia driver (nouveau). Installing Nvidia apt-get install nvidia-340 on the VM breaks this setup though.

qemu-ubuntu.sh

!/bin/bash
modprobe -r nvidia
modprobe -r nvidia_drm
modprobe -r nouveau

systemctl restart libvirtd
qemu-system-x86_64 \
 -machine type=pc,accel=kvm,usb=on \
 -cpu host,kvm=off \
 -smp 4,sockets=1,cores=2,threads=2 \
 -m 8G \
 -usb -device usb-host,hostbus=1,hostaddr=38 \ # lsusb bus addr for keyboard
 -usb -device usb-host,hostbus=1,hostaddr=43 \ # lsusb bus addr for mouse
 -device vfio-pci,host=01:00.0,multifunction=on,x-vga=on -vga none \ # lspci -nnk  turn off qemu display, use GPU
 -drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd \ # UEFI bios
 -drive if=pflash,format=raw,file=/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd \ # UEFI bios
 -drive file=/home/user/Downloads/ubuntu.iso,media=cdrom  # Ubuntu install image
# -drive file=/home/user/kvm/ubuntu.img,id=disk,format=raw # ubuntu storage disk

The GPU passthrough setup works flawlessly when using a Linux image apparently, But When I try booting a Windows disk/img though:

• Blackscreen
• Device Manager Error codes 43 & 31 / Driver cannot be installed (the previous issues mentioned above)

[ghostface]

@ghostface No, this is happening in the PKGBUILD. sed -i "s/103936/$rom_len/g" ssdt.asl

you are right - i missed it. I still can't get the code 43 to dissappear :/ nvidia gfx card shows up fine in windows 10 guest and installing the nvidia drivers works too but that's where I am stuck

[brandsimon]

@ghostface @KenMasters20XX Some people mentioned, that changing some qemu options did the trick for them. If this is successful for you, please let me know the hardware and the working and not working options.

EDIT: After copying much of Arne's libvirt XML I was finally able to say goodbye to Code 43 :)

[T-vK]

@dreamcast96 I currently have a notebook that is very similar to yours. (MSI, GTX 1060 Mobile, 8th gen i7) I have been able to pass the GPU through from a Fedora host to a Windows 10 guest and the Nvidia driver installed without issues. I "only" get error 43. But that's after installing the driver.

You might wanna check out my MobilePassThrough project which automates setting GPU pass-through up the way I did using some smart scripts.

https://github.com/T-vK/MobilePassThrough/

[jmandawg]

same here i7 8th gen, GTX 1060 (overpowered walmart) passed through to windows guest, but error 43. I wish this would get resolved, the hdmi ports on this laptop are wired directly to the 1060 so if it worked, it would be sweet.

[Verequies]

@brandsimon Which libvirt XML configuration are you referring to?

[brandsimon]

@Verequies

3. post:

   Attached you can find the libvirt XML that was used. win10-pci.txt

[ghost]

@dreamcast96 I currently have a notebook that is very similar to yours. (MSI, GTX 1060 Mobile, 8th gen i7) I have been able to pass the GPU through from a Fedora host to a Windows 10 guest and the Nvidia driver installed without issues. I "only" get error 43. But that's after installing the driver.

You might wanna check out my MobilePassThrough project which automates setting GPU pass-through up the way I did using some smart scripts.

https://github.com/T-vK/MobilePassThrough/

Thanks, very useful tool. Everything checks out when I run the compatibility check, it's just that Error 43 that i'm stuck on as well

[jmandawg]

Has anyone successfully gotten a muxless 10XX card to passthrough without "Error 43"?

[T-vK]

Not to my knowledge. Every record I could find is stuck at Error 43: https://gpu-passthrough.com/

[Verequies]

Try getting it working under a Linux VM, as stated earlier, I have successfully done this. Its a Windows issue thats causing the Error 43, and I believe its an error with the ACPI tables. But not related to the VROM, as I've confirmed its readable and 100% correct.

[T-vK]

DrownedFire mentions something about setting the root port address properly to fix error 43:

• Use the proper PCIe addresses: The IOH3240 (PCIe-Root-Port in libvirt) and dGPU need to have the proper PCIe address (see Bus-Device-Function (BDF) notation) to bypass error 43. A common address of the dGPU's IOH3420 for Muxless laptops seems to be bus=pcie.0,addr=01.0 which is equivalent to bus 0, device 1, function 0. A common address of the dGPU seems to be bus=root.1,addr=00.0 (or bus=ioh3420-root-port-1,addr=00.0in Verequies' script) which is equivalent to bus 1, device 0, function 0. The address value 01.0 (or 0x1) is used by the default network device so change it via -net nic,addr=0xa -net user or implement your own networking. You can use a Windows dual-boot or spare drive to find out the proper addresses for your laptop. Go to Device Manager -> Sort devices by connection, expand the topology, and check the properties of your dGPU and its PCIe Root Port/Controller. Edit: Just realized you could also just use lspci to find the proper addresses and lspci -tv to see the tree topology.

Maybe that could fix that problem?

[Verequies]

Yeah I can confirm it doesn't fix the issue - I do that currently already as is said in that comment quoted from the reddit page ( references me )

[T-vK]

Oh I didn't even realize it was the same name, sorry. :laughing: The last thing I can currently think of that could fix the issue would be the nvidia-kvm-patcher. But it needs to be updated first and that is incredibly difficult without knowing what exactly it does in the first place. @sk1080 himself hasn't shown any sign of life in over a year on GitHub. I have sent him an email though, maybe he'll answer that way... The only clue he gives in the source code on what the patch is doing is Write-Host '[+] Patching CPUID Check'. It might be worth it to unpack the nvlddmkm.sys file and scan it for "43" or existing CPUIDs and then use a disassembler to understand what is happening in the code around that. It might be as simple as replacing a JMP operation with a NOP operation in order to avoid "the check".

[ghost]

I gave up on my MSI GS63VR and just reinstalled Windows 10. While I was re-downloading all of it's required drivers from their support page (https://www.msi.com/Laptop/support/GS63VR-6RF-STEALTH-PRO#down-driver&Win10%2064), it made me realize a lot of things were missing when I had Linux installed. This laptop is not meant for this and Nvidia is a pain to work with. I'll be buying a new tower build with AMD GPUs this time, as they are not so problematic from what I've read

[birdsoup]

Oh I didn't even realize it was the same name, sorry. laughing The last thing I can currently think of that could fix the issue would be the nvidia-kvm-patcher. But it needs to be updated first and that is incredibly difficult without knowing what exactly it does in the first place. @sk1080 himself hasn't shown any sign of life in over a year on GitHub. I have sent him an email though, maybe he'll answer that way... The only clue he gives in the source code on what the patch is doing is Write-Host '[+] Patching CPUID Check'. It might be worth it to unpack the nvlddmkm.sys file and scan it for "43" or existing CPUIDs and then use a disassembler to understand what is happening in the code around that. It might be as simple as replacing a JMP operation with a NOP operation in order to avoid "the check".

I think that's just patching out a cpuid call and value check and replacing it with nops. This probably just accomplishes the same thing as hiding kvm and changing the vendor id using qemu

[T-vK]

However, it may still be a good idea to scan for "43" in order to find the root cause for what can cause that error and maybe skip the check.

[brandsimon]

@T-vK Using the proper PCIe addresses solved the issues for me, the PKGBUILD is working fine.

-net none
-vga none
-display gtk,gl=on
-device vfio-pci,bus=pcie.0,addr=02.0,sysfsdev=/sys/devices/pci0000:00/0000:00:02.0/uuid,x-igd-opregion=on,display=on
-device ioh3420,bus=pcie.0,addr=01.0,multifunction=on,port=1,chassis=1,id=root.1
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,romfile=vbios.rom

[T-vK]

@brandsimon Great to hear that! I'll add your Thinkpad P51 to the list! Which CPU does your device have?

[ArtyomFR]

Hi, I'm working on a ASUS X550V (nvidia 950M listed as 3D controller) to get the VGA passthrough working with a W10 guest. The last time I've tried i get a 43 error code and assumed it was because my graphic card doesn't support UEFI at all and give up. But I've read in the notes that it's apparently not mandatory for passthrough to work and decided to make another try. What I have today is a newly installed Archlinux dual-booted with a W10 and I already achieved to start the W10 as a guest with qemu wich means the nvidia drivers are already installed because the operating system was originaly used as a bar-metal one and not a guest. So my question is: What is your standard first procedure to get it working you do before fixing out the bugs? With that, I will be ensured that my problems are due to non-resolved bugs and not a failed basic configuration. I can send any command return if needed. Thank you in advance to anyone who takes the time to help me.

[T-vK]

What is your standard first procedure to get it working you do before fixing out the bugs?

I don't understand your question. What do you even mean by "it"? The patch is already part of "fixing out the bugs" imo.

[ArtyomFR]

What I mean by "it" is the VGA passthrough and what I don't really get is what do I need to do beside the patch and how to apply the patch. Thank you for the quick reply.

[T-vK]

There is a ton of things you potentially have to do. Why do you think that you need this patch though? Imo a good starting point would be the compatibility-check script I wrote a while ago from this project: https://github.com/T-vK/MobilePassThrough/

It should be able to tell you if there's even a chance of your notebook being compatible and if you need to change UEFI settings etc... The other scripts from that project are not yet compatible with arch out of the box, but if you know some bash, it is still useful to understand what else you'd have to do.

Another good resource is Misairu-G's tutorial: https://gist.github.com/Misairu-G/616f7b2756c488148b7309addc940b28 And the arch wiki in general has a lot of good information on this topic.

[ArtyomFR]

Ok, i will set up my laptop with the Misairu-G tutorial and check with your script if it's compatible. I think a rom patch could help me because i got few problems with the export and import of the roms. By example I am currently unable to save my rom from my video card with GPU-Z or with the cat and read method.

[T-vK]

Did you end up finding a way to extract it? If not I can help you with that.

[ArtyomFR]

Here is what give the method available on the Arch wiki:

# echo 1 > /sys/bus/pci/devices/0000:01:00.0/rom
# cat /sys/bus/pci/devices/0000:01:00.0/rom > /tmp/image.rom
cat: "/sys/bus/pci/devices/0000:01:00.0/rom": Erreur d entrée/sortie 'In/Out error in english'
# echo 0 > /sys/bus/pci/devices/0000:01:00.0/rom

When I tried with GPUZ it says that bios reading is unsupported on this device.

And here is what you compatibility script says about my system:

[OK] VT-X / AMD-V virtualization is enabled in the UEFI.
[OK] VT-D / IOMMU is enabled in the UEFI.
[OK] The IOMMU kernel parameters are set.
[Success] GPU with ID '01:00.0' could be passed through to a virtual machine!
[Error] Failed to find the IOMMU group of the GPU with the ID 00:02.0! Have you enabled iommu in the UEFI and kernel?
[Success] There are 1 GPU(s) in this system that could be passed through to a VM!

Is Compatible?  Name                       IOMMU_GROUP  PCI Address
Yes             GM107M [GeForce GTX 950M]  1            pci@0000:01:00.0

[OK] You have GPUs that are not in the same IOMMU group. At least one of these could be passed through to a VM and at least one of the remaining ones could be used for the host system.
[Info] Device name: X550VX
[Info] BIOS version: X550VX.302
[Warning] This system is probably MUX-less. (The connection between the GPU(s) and the [internal display]/[display outputs] is not multiplexed.)
[OK] Logs have been created in /home/gaetan/.tmp/MobilePassThrough/logs/X550VX/X550VX.302
If you found a notebook that appears to be GPU pass-through compatible, please open an issue on Github and let me know.
You may now proceed and run the start-vm script.
However, you should adjust how much RAM, CPU cores etc the VM can use at the very top of the script.
You should also look at the /home/gaetan/.tmp/MobilePassThrough/utils/Arch Linux//prepare-vm script and change the size of the VM disk to your liking.

[T-vK]

The script output looks good. It can't find the IOMMU group of your iGPU, which doesn't really matter. This can happen when tools like bumblebee are installed.

About your vbios ROM, you could either get an SPI programmer with a clamp to read the UEFI/BIOS ROM from the SPI flash chip that stores your UEFI/BIOS (they are like 5 bucks on aliexpress and ebay) or you could check the the manufacturers website of your device and try get the BIOS ROM. Then you can use tools like https://github.com/coderobe/VBiosFinder to extract the vBIOS ROM from it.

Edit: There appear to be two vBIOSes in the latest BIOS update I found for your device: https://www.asus.com/Laptops/X550VC/HelpDesk_BIOS/ I guess one is for the dGPU and the other one for the iGPU... I extracted them if you want to check it out: extracted_vbios_roms.zip

[Verequies]

You can also grab the VBIOS out of the registry on Windows. I've done that successfully a few times and the VBIOS 100% matches against one dumped directly from the card.

[brandsimon]

@T-vK Sorry, I forgot to answer. My cpu: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz My entry on https://gpu-passthrough.com/ is wrong. I have a linux guest and I passthrough both cards (nvidia and gvt-g) at the same time. In the guest I use bumblebee.

[T-vK]

@brandsimon Thanks for clarifying, I will correct this tomorrow. Edit: fixed.

[ArtyomFR]

@T-vK Thanks for the rom but it's actually not from the right BIOS. You took the X550VC (gtx 750m) but mine is X550VX (gtx950m) with this BIOS: X550VXAS302.zip. But i've got some problems to extract the VBIOS myself with the script because of some ruby error:

./vbiosfinder extract X550VXAS.302 
output will be stored in '/home/gaetan/.tmp/VBiosFinder/tmp-vbiosfinder'
checking for ruby... yes
Cleaning up garbage
Traceback (most recent call last):
    14: from _init.rb:7:in `<main>'
    13: from /home/gaetan/.tmp/VBiosFinder/vendor/bundle/ruby/2.6.0/gems/thor-0.20.0/lib/thor/base.rb:466:in `start'
    12: from /home/gaetan/.tmp/VBiosFinder/vendor/bundle/ruby/2.6.0/gems/thor-0.20.0/lib/thor.rb:387:in `dispatch'
    11: from /home/gaetan/.tmp/VBiosFinder/vendor/bundle/ruby/2.6.0/gems/thor-0.20.0/lib/thor/invocation.rb:126:in `invoke_command'
    10: from /home/gaetan/.tmp/VBiosFinder/vendor/bundle/ruby/2.6.0/gems/thor-0.20.0/lib/thor/command.rb:27:in `run'
     9: from /home/gaetan/.tmp/VBiosFinder/src/cli.rb:34:in `extract'
     8: from /usr/lib/ruby/2.6.0/fileutils.rb:418:in `cp'
     7: from /usr/lib/ruby/2.6.0/fileutils.rb:1555:in `fu_each_src_dest'
     6: from /usr/lib/ruby/2.6.0/fileutils.rb:1571:in `fu_each_src_dest0'
     5: from /usr/lib/ruby/2.6.0/fileutils.rb:1557:in `block in fu_each_src_dest'
     4: from /usr/lib/ruby/2.6.0/fileutils.rb:419:in `block in cp'
     3: from /usr/lib/ruby/2.6.0/fileutils.rb:492:in `copy_file'
     2: from /usr/lib/ruby/2.6.0/fileutils.rb:1385:in `copy_file'
     1: from /usr/lib/ruby/2.6.0/fileutils.rb:1385:in `open'
/usr/lib/ruby/2.6.0/fileutils.rb:1385:in `initialize': No such file or directory @ rb_sysopen - X550VXAS.302 (Errno::ENOENT)

I would be thankfull if you could find the time to extract them. EDIT: I found that the script only accept absolute path, if you don't want to install rom-parser and UEFItool you must put all the binaries in the 3rdparty directory. I manage to get the rom ( VBIOS_X550VX.zip) and i will try them asap.

[ktod16]

Hi all,

I have a Thinkpad P71 / P4000 gpu + Fedora 29 +Win10 and for a few days I'm trying to make this Pass through work without success. I tried different tutorials I found online but no success. I almost quit until I discovered "T-vK" automatic script. What I did by now: Inside kvm I didn't installed windows from .iso. I just separated the pre installed Win 10 SSD from the iommu groups, I assigned it to kvm and I set kvm to boot from Win SSD instead from the loaded .iso. This worked great I could login directly in my pre installed Win installation.
I installed Team viewer on Windows and Linux and all was great until Code 43 and Max screen resolution 640x480. Nvidia driver installation is not working in Windows. I installed driver in Device manager -> update driver and selected .inf file already present.

I extracted VBIOS from GPU-Z and from regedit also. Just to see if it works, don't know what to do with it.

I am new to linux (I installed it precisely for this topic). I really don't like the looks of Win10 this is why I want to try something new. @brandsimon I see that you managed to make P51 work. Please write a "HOW TO" so I can follow your steps. @T-vk I tryed to run your automatic script but I get some errors: ".......utils/Fedora/29/kernel-param-utils: No such file or directory after this, it installed a lot of updates and stuff....and at the end errors again. ".........utils/Fedora/29/set-kernel-params: command not found" ".........utils/Fedora/29/nvidia-setup: command not found"

I copied all the script files in both utils and 29 folders to be sure they are everywhere and I get the same errors.

Thank you for support.

[ArtyomFR]

@ktod16 Did you manage to hide KVM from your W10? Because nvidia drivers won't work if it detect that the environment is virtualised and that might be what's causing your problem.

[ktod16]

@ArtyomFR How do I do that? The funny thing is all the tutorials I followed by now are for PC systems. Just yesterday I discovered that there is a special process for laptops and all the MUXless disaster.

[ArtyomFR]

According to Arch wiki you can edit the XML file of your VM like this:

<features>
    <hyperv>
        ...
        <vendor_id state='on' value='whatever'/>
        ...
    </hyperv>
    ...
    <kvm>
    <hidden state='on'/>
    </kvm>
</features>

You can verify if Windows know it's virtualized by checking the task manager, it should not print info about virtual CPU.

[ktod16]

Yes I did that... I removed completely hiperv section and I added kvm section.