Very hacky solution for Windows guest #2
Comments
|
Hi Arne, Thank you for this! I didn't realise anyone else was still looking into this. I've not had too much time to do so myself lately sadly. I'm glad to hear this got it working for you. To try and figure out what's going on here, could you please let me know the following about your setup?
Also, can you confirm that loading the same VROM via the original ASL in this repository (without your OVMF patch) did not work on your hardware? I may well be missing something as this whole area is quite new to me, but I'd have expected them to have the same result, as the interface to the Nvidia driver itself (the Cheers, |
|
Hi Jack A Virtio GPU was assigned as the primary graphics adapter for my guest. I can confirm Error 43 still occurred when I tried using the original ASL table and passed the VROM as a PCI ROMBAR. As you wrote in this post that Windows clears the ROMBAR image once booted, I quickly switched to the RuntimePool approach. Kind regards |
|
Thanks for the information. It's interesting that it worked for you without a GVT card. I will have to try that scenario again myself, with a fresh VM in case perhaps there is something broken in the one I've used so far. The filename in the FWGS call is simply whatever filename the ROM ends up as in fw_cfg. I named it according to hardware IDs in my case (vendor, device, subsystem) as I intended to eventually make the ASL generic and to just read the PCI IDs from the device at PCI address 1:0:0 and load the appropriate image. I'll give things a try on my machine with your method when I have a bit of free time and will reply back here with the result. |
|
Myself and a few others have had a chance to test your patch, and I can confirm it works as far as getting further than the code 43 error :) Unfortunately, none of us have had any luck getting 3D workloads going in the guest - were you able to do so in your setup? |
|
After further testing, I can confirm 3D workloads do in fact work. What currently doesn't work (and I suspect this is the same with any RemoteFX-based setup), is fullscreen mode. I suspect we might need to emulate an Optimus setup in the VM with GVT for this to work, but thus far I haven't been able to get GVT itself to work (even without a Nvidia card involved) |
|
Nice to hear the patch helped you to finally get rid of code 43 :-) In my setup some simple 3D rendering tasks seemed to run on the GPU, but I did not test this in detail and never in full screen mode. It will also take a while before I can try out something new as my own laptop is currently sent back to the manufacturer for repair. |
Not quite. To clarify, it has nothing to do with whether or not the RDP client is fullscreen, but rather, whether the application (within the VM) itself runs in fullscreen. There are a few ways to reproduce this:
I do not get the Code 12 error - I suspect @Misairu-G had something else broken in their setup. I can get GVT working (and even run 3D workloads on the GVT card) if a QXL card remains the primary VGA in the VM. What I have not been able to get working is GVT as primary VGA in the guest. There's ongoing work by Intel on this (specifically GVT dmabuf and x-display support), but it is still quite raw. Judging by this document, having GVT working as primary VGA will be necessary to trigger the hybrid-graphics behaviour in the Windows graphics stack. |
|
Thanks for the explanation. It gives me a better understanding of the problem now. |
|
After a bit of testing, I've found the following things:
Going forward, I think this leaves us with a few options:
|
|
For anyone else looking at this, an updated OVMF patch generated against current OVMF git master is here |
|
After a bit of experimentation, and a patch from upstream OVMF, I got GVT-g local display support working on my machine. Unfortunately, this does not result in a valid hybrid graphics setup, as the emulated display is a regular DisplayPort device, and as per Microsoft documentation, the iGPU needs to expose an embedded display panel of some kind. At this point, there are two options to potentially get this working, but both are beyond my current knowledge/expertise, and I sadly don't have much free time to get up to speed in these areas:
|
|
@jscinoz @arne-claeys - just trying to investigate whether this would allow gaming in a windows guest on a linux host? I have a a Dell Precision 5520 via work, which has a Quadro M1200. Like the XPS’s, I believe this is a muxless setup, and appears as a 3D controller. I see you mentioning ‘rendering workloads’, and indeed games based in Unreal engine, but still unclear on current state, or what the potential is here on a laptop with this setup? |
|
I found a good guide to the current status here: https://www.reddit.com/r/VFIO/comments/8gv60l/current_state_of_optimus_muxless_laptop_gpu/ Appears to mention @jscinoz’s work. |
|
Sadly I didn't have any luck with getting this to work. I did however create a PKGBUILD that complies OVMF with the vBIOS patched in for people that want to test it out quickly (and are running Arch Linux). Just place your rom in the same folder, name in |
|
@Ashymad - any ideas how to get the VBIOS for something like the Dell XPS or Precision 5520? |
|
@marcosscriven I'd imagine the VBIOS is included in the system BIOS, so you will not be able to use tools which try to dump the VBIOS from the PCIe bus like you'd do for a discrete card. The easiest way is probably to try booting up windows on bare metal, then grab the vbios from the registry. I found a guide on how to do this here: https://forums.laptopvideo2go.com/topic/32103-how-to-grab-a-notebooks-vbios-that-is-not-supported-by-nvflash/ Another way would be to decompile your system BIOS and grab the VBIOS rom out of that. On a HP, I was able to go to support.hp.com, search my model, download the BIOS update, run it, but don't actually go through with flashing your BIOS. Just allow it to unpack, then look in C:\windows\temp or %appdata% to see where it put everything. Some installers you may be able to unpack with 7zip. Once you have the system BIOS, you'll need to find a copy of Phoenix BIOS Editor, or some similar tool to decompile the UEFI image into its individual firmware blobs. This gave me a bunch of files with names like 4A640366-5A1D-11E2-8442-47426188709B_1693_updGOP.ROM. From there I was able to grep these ROM files for "Nvidia", and I found a copy of my VBIOS that way. |
|
Thanks so much @pseudolobster - extracting via the linked how-to worked a treat on the Dell Precision 5520. In case that link disappears in future the basic overview is:
|
|
@pseudolobster @arne-claeys @jscinoz I extracted the bios from windows reg, but it seems to be of type According to https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF that means this won't work with passthrough. Do you know a way around that at all please? |
|
@marcosscriven vBIOS being UEFI compatible is only needed with the romfile QEMU method. It is not needed when patching OVMF. I am successfully using PC-AT vBIOS.
…On July 21, 2018 12:06:20 AM GMT+02:00, Marcos Scriven ***@***.***> wrote:
@pseudolobster @arne-claeys @jscinoz
I extracted the bios from windows reg,
But it seems to be of type `x86 PC-AT` rather than `UEFI`:
```
PCIR: type 0 (x86 PC-AT), vendor: 10de, device: 13b6, class: 030200
PCIR: revision 3, vendor revision: 1
Last image
```
According to
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF that
means this won't work with passthrough.
Do you know a way around that at all please?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2 (comment)
|
|
@arne-claeys @jscinoz Thank you both very much for your work here. nouveau: bios: unable to locate usable image Any ideas how to resolve this or where I should be looking? Is there a way to verify that the OVMF firmware I've compiled does in fact have the vBIOS embedded? Edit: I fixed it! Seems that the firmware was fine all along but there was an address problem in the ioh3420 configuration of my qemu script |
|
I created a patched OVMF for my Nvidia Quadro M1200 (per https://github.com/marcosscriven/ovmf-with-vbios-patch) However, I still get I've ensured those patched versions are in use, and KVM is hidden etc. I've also ensure the device is passed through with: I tried both with and without the IOMMUS looks to be all setup ok: dmesg show the vfio_pci added: And finally lspci shows the card is bound to vfio-pci driver: Any ideas please? |
|
@hardeepd - can you share how you worked out the ioh3420 settings and your xml confit please? I’ve posted my own PCI tree above. |
|
For reference I did finally get this working https://github.com/marcosscriven/ovmf-with-vbios-patch/blob/master/qemu/win-hybrid.xml The tricky thing is if the GPU is attached via a bridge, you need to specify that connection: |
|
Hey @marcosscriven, I think I'm experiencing a similar problem. I successfully passed my dGPU to the Windows 10 x64 Guest, using @Ashymad's PKGBUILD to patch the OVMF with my vBIOS. That got me to the point were I was able to install NVIDIA drivers, but after that I'm stuck with code 43. Could you please post your entire xml? the link above did not work for me (404). Thank you very much. |
|
All my config for this is in the same linked repo https://github.com/marcosscriven/ovmf-with-vbios-patch |
|
Sadly I had no luck, so I turn to you guys :). I'm trying to do this with my MSI GS63VR 6RF, it should be a muxless laptop with a GTX1060 dGPU. What's interesting is that the dGPU should be directly connected to the HDMI output, so I was hoping to pass the 1060 to a Win10 guest and use an external monitor connected to the HDMI (don't know if that's possible). The relevant IOMMU groups are: and also here's my full libvirt xml: At this point I've tried a lot of different things: patching NVIDIA drivers, removing the VIRTIO primary GPU, booting with the external monitor plugged in, but I'm still getting code 43 after I install NVIDIA drivers. I've also checked the vBIOS and it seems that the one I used to patch OVMF is the right one, because it's an exact match to the one I extracted with nvflash from inside the VM. Thank you all for your assistance. |
|
I'm posting to confirm that I have a very similar configuration as @kalelkenobi . I'm using a Gigabyte Aero 15X v8, with GTX 1070 Max-Q and yet I'm stuck with Code 43. I've tried every configuration posted in this repo, as well as in the other dGPU repo, and none of them seem to work. In Windows, the Nvidia driver installs perfectly fine without complaint, and yet reports Code 43. I've patched my OVMF using the provided PKGBUILD up-thread. I've tried passing my vBIOS ROM separately, alongside, or not at all. I've tried with and without ROM BAR enabled. I've tried SeaBIOS and UEFI both, i440fx and Q35. Perhaps this information can help someone figure this out but as of now, I am at a bit of a loss. What I have learned is that my particular graphics configuration has the following characteristics:
Some suppositions on my part: I don't believe this card has a UEFI 'BIOS', either on it's own discrete EEPROM or in the system firmware. That might be true of all the Max-Q model cards? My guess is that these designs are completely relying on the iGPU at boot and operate in CSM-mode only with a legacy BIOS. I don't think any of these laptops can operate with the iGPU off, nor can any of them disable the internal display or remain functional at bootup with the internal display disabled (if done through a BIOS hack). At this point, I'm left attempting a few other alternatives, but I think I've fully explored the possibility that the VM isn't getting the correct BIOS -- as far as I can tell, it is. I've used @marcosscriven 's configuration as well as many other iterations, and yet, nothing works for me. Next steps would be to try the ACS patch (because there is a hidden PCIe HDMI audio component at 0000:01:00.1 that I cannot passthrough). Or.. to try to use a UEFI-enabled GTX 1070M BIOS patched OVMF (assuming compatibility with Max-Q). Or.. try patch my own custom Pascal BIOS for the Max-Q, based on combining the 1070M UEFI-enabled BIOS with the 1070 Max-Q and then flashing that to my card (I can flash back with programmer if it fails, so no worries there) and hoping that by effectively turning the card into a UEFI-compatible card that it might help? Any thoughts, ideas, would be greatly appreciated. Would really like to get this working and it seems I'm right very close and I'm maybe missing something trivial? I get the feeling that maybe I'm spending a lot of time on this BIOS issue and it's something completely different? Thanks! |
|
@KenMasters20XX thank you for your intensive testing. I believe I am in the same situation as you are. My GTX 1060 is NOT a Max-Q design, but I’ve jumped through the same hoops as you have trying to confirm that I had in fact a valid BIOS (short of using an eeprom programmer) and came to the same result. The Guest seems to be getting the right BIOS and there is no way to extract a UEFI compatible dump from the card or the BIOS updates. Tried all the same setups you did (q35, i440fx, patches OMVF, regular OVMF, etc...) with no luck. Unfortunately there’s little else I can contribute aside from confirming some of your guesses: my laptop cannot in fact operate with the iGPU or internal display disabled (I tried via unlocked BIOS). I’ve also tried using a downloaded vBIOS that seemed a close match to my own, no luck. Lately I’ve been focusing my attention on the PCI hierarchy, thinking maybe I missed something there. I hadn’t found the hidden PCI device, although I suspected it existed. Do you guys think that could be it? Maybe the HDMI audio needs to be passed on for the card to work properly. bare metal windows seems to be able to use it, even though it doesn’t show up in device manager. |
|
@kalelkenobi I think we're the two users in this thread so far with Pascal cards? I think perhaps everyone else is using Maxwell-based cards and that might make the difference. So far, I've not found any instances online of either an integrated or MXM-based Pascal card being successfully passed-through. What is interesting is that MXM cards like the 1070M do in fact have a UEFI BIOS; however, the integrated cards, even though they show up as VGA Controller, and have control over the HDMI ports, do not have an associated UEFI module. My guess is these cards simply do not have UEFI-functionality by design? I'm going to retrieve my firmware's Gop Driver and take another look, but IIRC, there was no indication of an Nvidia driver there. Now, if that's true; then perhaps that's what's causing the Code 43? If not, then there's a UEFI module that I'm simply missing... BTW; the 'hidden' HDMI Audio device does indeed exist, I've seen it "accidentally" exposed by toggling the power-state via ACPI calls. At various times (seemingly at random) the HDMI device will show up in lspci. This is one of the reasons I'm thinking of using an ACS-patched kernel in my next series of tests, simply to isolate this as a possibility. Lastly, I'm thinking that perhaps the ACPI tables might be a difference-maker here. I've taken a cursory look at the Aero 15X's SSDT table and I'm guessing that, perhaps like a Hackintosh, there is some incompatibility here between what's been posted and what the Nvidia driver is expecting to see for an integrated Pascal GPU. Hard to really say with any certainty since this amounts to shooting in the dark. |
|
@KenMasters20XX I'm no nowhere near as versed as I'm guessing you are on BIOS and ACPI inner workings, that is why I got stumped on the no-UEFI dump front and essentially gave up on that angle. This is simply way over my head, that's why I'll try and look at the HDMI audio angle. I was able to find a way too old bug about this: https://bugs.freedesktop.org/show_bug.cgi?id=75985 I'll try passing it over to the guest and see if that makes any difference, but I'm not holding my breath. As you pointed out very few people tried this on pascal optimus laptops and I have not been able to find anyone who actually succeded. |
Hi! I went through these guides, but I still get error 43. I've taken your XML from Jan 4 post, because I have the same laptop as you (ThinkPad P71). <kvm>
<hidden state='on'/>
</kvm>
<qemu:commandline>
<qemu:arg value='-cpu'/>
<qemu:arg value='host,hv_time,kvm=off,hv_spinlocks=0x1fff,-hypervisor'/>
<qemu:arg value='-acpitable'/>
<qemu:arg value='file=/var/tmp/SSDT1.dat'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-pci-sub-vendor-id=6058'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-pci-sub-device-id=8780'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.bus=pci.1'/>
</qemu:commandline>When I start virtual machine I get error: Error starting domain: internal error: qemu unexpectedly closed the monitor:
qemu-system-x86_64: -acpitable file=/var/tmp/SSDT1.dat:
warning: ACPI table has wrong length, header says 1095060310, actual size 219 bytes
2020-12-08T10:28:48.021359Z qemu-system-x86_64:
-device vfio-pci,host=0000:01:00.0,id=hostdev0,bus=pci.5,addr=0x0:
PCI: slot 0 function 0 not available for vfio-pci, in use by e1000e/var/tmp/SSDT1.dat from U1NEVKEAAAAB9EJPQ0hTAEJYUENTU0RUAQAAAElOVEwYEBkgoA8AFVwuX1NCX1BDSTAGABBMBi5f
U0JfUENJMFuCTwVCQVQwCF9ISUQMQdAMCghfVUlEABQJX1NUQQCkCh8UK19CSUYApBIjDQELcBcL
cBcBC9A5C1gCCywBCjwKPA0ADQANTElPTgANABQSX0JTVACkEgoEAAALcBcL0Dk=I don't understand what I have to get. Will screen work only with external HDMI monitor or only with FreeRDP client? |
|
@x0r2 I think your problem comes from this "PCI: slot 0 function 0 not available for vfio-pci, in use by e1000e". Pci you want to asign to gpu is in use by network card. Have you managed to start up the VM without gpu passthrough? |
I have the same as your device ids (x-pci-sub-vendor-id=6058 and x-pci-sub-device-id=8780) but I have different NVIDIA card. Is it right? Sorry for my English. |
|
I fixed this error by changing bus id for network device from 0x01 to 0x11 (because NVIDIA device had the same bus id). And first warning was appear because I forget decode base64 SSDT1.dat. Now I don't get any errors or warnings. But after starting Windows, I see 43 error in device manager. IOMMU Group 1:
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 05)
01:00.0 3D controller [0302]: NVIDIA Corporation GM107GLM [Quadro M620 Mobile] [10de:13b4] (rev a2)
01:00.1 Audio device [0403]: NVIDIA Corporation GM107 High Definition Audio Controller [GeForce 940MX] [10de:0fbc] (rev a1)Should I passthrough "00:01.0 PCI bridge [0604]: Intel" to qemu also or enable GVT-g? What do you think, what I could do wrong? |
|
It's working without VBIOS patch on ThinkPad P71 (Nvidia Quadro m620). It's NOT working for me with pci bus setting, I don't know why, I spent lot of time for this problem: <qemu:arg value="-set"/>
<qemu:arg value="device.hostdev0.bus=pci.1"/>My working settings: <!-- vendor_id in hyperv section -->
<vendor_id state='on' value='GenuineIntel'/>
<!-- hide kvm -->
<kvm>
<hidden state='on'/>
</kvm>
<!-- sub-vendor-id and sub-device-id -->
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-pci-sub-vendor-id=0x17aa'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-pci-sub-device-id=0x224c'/>
<!-- ACPI battery -->
<qemu:arg value='-acpitable'/>
<qemu:arg value='file=/var/tmp/ssdt1.dat'/>I used Nvidia driver which installed by Windows automatically. |
Can you post your grub config and full current xml? |
|
Spent few days but was able to passthrough dGPU on my Gigabyte Aero 15 laptop. FurMark FHD score 3655pts, 61FPS, 75C max temp. Maybe somebody knows how to be able to use dGPU in Linux when it is not needed for VM without reboot? ==== Found another problem: ==== |
|
@x0r2 Can you please share your libvirt xml configuration? I have a thinkPad P15V. the Windows guest identify the card and I can install the driver correcly but when I reboot the GPU give the error 43. In the Windows task manager performance tab I can't see the GPU though I have driver correcly installed. Thank you. PS. I have a similar IOMMU situation like yours but I don't see the Audio device. |
|
Hi I would like to share my setup too. I'm using a Thinkpad P50 with Quadro M2000M, it has a gpu layout that goes something like this (from the schematics): My host is as follows:
This issue and this guide have been a huge help! And the keys for my setup were the proper PCIe location in the VM and passing a GOP updated vBIOS, otherwise I'll be met with Error 43 or no display. To get the M2000M working properly I had to: (I assume you've read Archlinux's wiki about OVMF GPU Passthrough and how to add stuff like qemu commands in a virsh xml)
<source>
<address domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</source>
<!--...-->
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0" multifunction="on" />
<source>
<address domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</source>
<rom file="/ext/qemu/vbios_10de_13b0_1_updGOP.rom"/>
<!-- match it to your own path -->
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0" multifunction="on" />
<qemu:arg value="-set"/>
<qemu:arg value="device.hostdev1.x-pci-sub-vendor-id=6058"/>
<qemu:arg value="-set"/>
<qemu:arg value="device.hostdev1.x-pci-sub-device-id=8750"/>
<qemu:arg value="-set"/>
<qemu:arg value="device.hostdev1.x-pci-vendor-id=0x10de"/>
<qemu:arg value="-set"/>
<qemu:arg value="device.hostdev1.x-pci-device-id=0x13b0"/>
<qemu:arg value="-acpitable"/>
<qemu:arg value="file=/home/midi/Downloads/SSDT_BAT.dat"/>These were the requirement to get my setup working and I got output through HDMI (and the TB3 port through a hub, no need to pass the hub through it as it supported DP-Alt). If any of them isn't present then I'll be met with either no display or Error 43. Issues I encountered:
Other finding:
What I'm trying to do next:
My XML for my setup here. If I find anything new I might edit this comment. |
|
I wonder if this applies to laptops: |
You need the acpi battery patch, but no vendor ID and KVM off. Without the battery the notebook driver simply gets mad because you're not using a laptop, and that's not going to change. |
This actually works with quadro cards too! But also if you install the same driver package version of the quadro drivers it won't work! I just tried it on my M2000M, the Gefore drivers install and work while the quadro ones complain. |
Hi @midi1996, would please share how to use Geforce drivers with quadro cards? I have HP Zbook 15 v5 with Quadro P2000. I have tried almost all tricks but always getting |
I just downloaded their regular drivers and installed them, nothing special. |
|
@midi1996 Followed the guide you cited and after a few roadblocks Did you run across this? |
@EvanBenechoutsos I fixed it, I forgot to comment some lines that made links to the python2 binary because old edk2. You can try now, it should be fixed. |
|
@PiemP, I spent lot of time for this problem and I went by another way. I didn't take other configs. I created new virtual machine as usually and then I was changing places in XML configuration:
xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"
<vendor_id state='on' value='GenuineIntel'/>
<hidden state='on'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-pci-sub-vendor-id=0x17aa'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-pci-sub-device-id=0x224c'/>
<qemu:arg value='-acpitable'/>
<qemu:arg value='file=/var/tmp/ssdt1.dat'/>All changes: xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"
<features>
<acpi/>
<hyperv>
<vendor_id state='on' value='GenuineIntel'/>
</hyperv>
<kvm>
<hidden state='on'/>
</kvm>
</features>
<qemu:commandline>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-pci-sub-vendor-id=0x17aa'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-pci-sub-device-id=0x224c'/>
<qemu:arg value='-acpitable'/>
<qemu:arg value='file=/var/tmp/ssdt1.dat'/>
</qemu:commandline>After changes check that your config saved correctly. I was adding Nvidia GPU from virt-manager GUI. May be this solution helps you. Sorry for my late answer. |
|
Hey everyone, is it possible to use the OVMF patch mentioned in the first post as well as the battery ACPI table? My understanding is that they both work by overriding the SSDT ACPI table. So I'm wondering if by using them both, the battery SSDT table will win over the SSDT table that has been patched with the vBIOS ROM or if you can simply have multiple SSDT tables at the same time. |
|
You can have multiple ssdts at the same time as long as they’re not
conflicting with each other. You can load the battery ssdt through
qemu/libvirt after the fact (no need to integrate it in the ovmf image).
…On Sun, 18 Jul 2021 at 21:11 T-vK ***@***.***> wrote:
Hey everyone, is it possible to use the OVMF patch mentioned in the first
post
<#2 (comment)>
as well as the battery ACPI table
<https://www.reddit.com/r/VFIO/comments/ebo2uk/nvidia_geforce_rtx_2060_mobile_success_qemu_ovmf/>
?
My understanding is that they both work by overriding the SSDT ACPI table.
So I'm wondering if by using them both, the battery SSDT table will win
over the SSDT table that has been patched with the vBIOS ROM or if you can
simply have multiple SSDT tables at the same time.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABFGDZWYYM5T6DWLR2UF6HTTYMYORANCNFSM4EXENXFQ>
.
|
|
@kalelkenobi @KenMasters20XX @spacepluk Hi guys I have similar setup (mobile Pascal card) and I was inspired by @ghostface's reply (RVBS should be set to correct value) so I did a quick check. From the virtual machine I can confirm that the SSDT is correctly loaded. However, when I use the kernel module More info on my setup
How I used ACPI calls on LinuxFirst install and load the kernel module acpicall () {
echo "$1" | sudo tee /proc/acpi/call > /dev/null
sudo cat /proc/acpi/call
echo
} |
|
Hi! I'm trying to passthrough RTX3070 Mobile to Windows VM. Seems that in this generation it is trickier. I can passthrough GPU, but Dynamic Boost 2.0 is not working. Device NVIDIA Platform Controllers and Framework cannot start with Code 31. I rebooted into Windows and found that this is driver for device ACPI/NVDA0820 I checked ACPI tables - there is one SSDT table from NVIDIA. I've attached a dump from RwEverything. Seems like it is the key to get DB2.0 working in VM. Is there any way to insert this ACPI table to VM? I tried to add it with -acpitable but Win10 crashes with ACPI_BIOS_ERROR I also got error when starting VM in dmesg |
|
Sorry for getting up an old topic, but did you find a solution? @Tualua |
|
Ok so i went over all of this for a week now and I'm fairly confused how this whole thing even worked for anyone else then OP. I might get things wrong here but the following are my observations.
This suggests that the ACPI path that the rom is attached to in ssdt.asl differs from laptop to laptop. The problem here is that this address will change depending on what pci address and pcie-root-port the gpu is attached inside the VM. So the pcie-root-port is on 00:1c.0 while the gpu is on 01:00.0 attached via the pcie-root-port. As great as this all sounds, I still cant get around Code 43 in windows even with the exact same pcie layout and acpi patch. I know that all of this is now really long ago and no one seems to care for this topic anymore but i do really wonder why that is. I suspect newer laptops just dont have this weird vbios issue? Or interest in gpu passthrough just stagnated? Anyways, I documented my findings here. Maybe they will be useful for anyone going over this. I will maybe try to debug the nvidia driver on windows to see what prevents it from loading but after having the breakthrough on linux with everything working while windows doesnt do anything on the same config kinda killed my motivation. |
|
@ZiemlichUndead Did you try adding a fake battery yet? https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#%22Error_43:_Driver_failed_to_load%22_with_mobile_(Optimus/max-q)_nvidia_GPUs
From my experiments, NVIDIA drivers didn't care where you put the GPU as long as you provided a working _ROM method at the GPU device node. This is sufficient enough for Linux guests. For Windows, I also need to apply custom vendor_id, hide KVM state, and a fake battery. I don't know when but for me this specific patch is not working for Linux guests anymore because the name collision between I fixed it by put _ROM in the QEMU device scope instead of adding a new device, which also get rid of _ADR stuff. Here is my custom SSDT if you're interested: https://github.com/lion328/gpu-passthrough/blob/master/ssdt.asl
I don't think Windows use different ACPI addresses given that it's QEMU who assign them. I think you can check it in Device Manager under the BIOS device name though. |
|
@lion328 Yeah I did the fake battery and all of the things in the arch wiki right away before even trying to get behind the acpi stuff.
Not sure if I get you correctly. You agree that the acpi address for the patch should be changed to where the GPU is mounted, right? You mention this calculation in your script: With this setup and the ovmf patch changed to |
Yes.
That's a pretty normal topology. My laptop is similar except the root port is at 00:01.0. Doing the calculation in reverse, PCI0.SE0.S00 means S00 is at 00.0 of its parent SE0 and SE0 is at 1c.0 of its parent PCI0. Also thanks for testing my script.
The patch added new ACPI devices using External (\_SB.PCI0.SE0.S00, DeviceObj)
Scope (\_SB.PCI0.SE0.S00) {
...
}Basically, instead of adding a new device, this extends the functionality of the already existing device instead. And also remove every _ADR definitions since QEMU will set it for you. FYI, _ADR of SE0.S00 and SE0 should be 0 and 0x1C0000 respectively. Check the ACPI spec to see how it's calculated. For my SSDT, the primary change is that the table will now uses QEMU fw_cfg to load ROM dynamically from the file I specified in the XML, instead of loading it from patched OVMF. I also fixed the conflict mentioned above, included my own version of a fake battery device, and removed unused code. I compile it manually using iasl and pass it to VM like the fake battery table. IMO, it's much easier than maintaining a custom version of OVMF, which is the main reason why this exists. |
|
@lion328 My god thank you so much I just booted into my windows vm using your ssdt and saw my GPU appear in taskmanager for the first time ever. Somehow your ssdt doesnt work for me with linux on nvidia drivers even tho nouveau works with it. Maybe this is caused by my weird pcie setup which im still using right now.
Yeah I think I get it now. The location of the pcie-root-port will be used to calculate PCI0.SXX.S00 while the location of the device itself will result in PCI0.S00.SXX right? Anyways you did amazing work here. I was kinda proud of myself for finding some stuff out about these ACPI paths and PCIE adresses but you actually solved the whole problem in a way better way. Again, thank you so much <3 |
|
@ZiemlichUndead Glad to see it's working!
Is there any warning or error in dmesg? A dump of guest's ACPI tables would be nice,.
Pretty much in this case yeah. |
Actually nevermind I didnt blacklist my drivers correctly. Now its working perfectly just like in windows. My bad.. |
and others
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.
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.
buildtable.txt
In my case this made the Error 43 finally disappear.
I hope this could be of any help.
Kind regards
Arne
The text was updated successfully, but these errors were encountered: