Did you enable the card in windows device manager?
1 Like
Well, that definitely worked. Had to reinstall the drivers, but removing the sections in the xml file works perfectly.
Now I am getting weird inception-like mouse problems. It needs to be inside the (small) window on the Fedora desktop to work on the other monitor, and if you leave the other monitor it comes out of the window and I have to get it back into the window. Need a way to lock and unlock the mouse and keyboard to the vm.
Yeah, you still have some ground to cover....in my case I wound up passing one of the USB controllers to the KVM and giving it it's own mouse, I do share a keyboard because I use a game pad that is also virtually passed to the KVM, but congratulations....it's all down hill from here.
And I guess you have used Fedora long enough to know about the multi desktop stuff, and how to reclaim that space that the virt-manager / QEMU console is using, there is a lot more to do, but you'll figure it out, if you have any questions just ask.
Yeah, I know about the multi desktop stuff. I might get a third monitor or a TV for the Windows VM sometime down the road. For now, though, I am very happy that it's working. Next up is to see if it can game.
Thank you so much for your help. Hopefully someone having similar problems can find this thread and glean something from it.
It's no problem, yea we need many more people doing this.....BTW I'm running Fallout 4 on my setup, not the best but it is very playable and will get better as soon as AMD gets it's drivers sorted out. One thing you are going to notice gaming is latency in the sound if you are sharing the sound card, it's on my list this winter to add a USB sound card to the KVM to take care of that on my system.
I might also kinda' warn you about stopping and starting the KVM a lot, the resources that are shared virtually with the KVM are un-binded from the host when you start the KVM, then re-binded to the host when the KVM is shut down, it has on many systems (mine included) at times caused instability in the host system if you do it a lot, I just leave my KVM run all the time since it has it's own monitor...but it's something to be aware of...good luck!
I have to say, this is pretty amazing. We truly live in an amazing time. I did the classic "But, can it play Crysis?" test, and I can confidently say yes it can. I get a steady 90 to 100 FPS with everything set to high. It's spectacular.
I am having one lingering problem, and for some reason it got worse.
At first I had sound, and it was clipping, but it was very minor. I could live with it. But I just started everything up after having the computer off for a day, and now I have absolutely zero sound in the Windows 8.1 VM. I tried changing settings, I tried all sorts of things, but nothing seems to fix it. I have no idea what happened.
I can pass through the onboard sound, and it works, but it disables it in the host. I can do that in a pinch, but I'd rather get the sound working the way it was. Any ideas?
Maybe....tell me about your setup, the hardware side and your virt-manager / QEMU configuration, I share a sound card, it's flaky at best but always seems to work, of course it has varying amounts of latency, yesterday I played Fallout 4 for about 6 hrs and at first the sound had about 3-4 sec of latency but after about 20 min I noticed it was like a second or two and was almost in sync.
I know there are things you can do to your configuration that may or may not help, from my point of view on my system I need a second sound card to solve the issue.
You might read through this thread, there are several people talking about the sound issues and changes they made.
https://forum.teksyndicate.com/t/gpu-passthrough-with-kvm-have-your-cake-and-eat-it-too/82250
Hello all, I am trying to pass through an ASUS Strix AMD R9 390 to a Windows 10 pro guest on an asrock X99 Fatal1ty motherboard. Everything on the host side looks fine, but when I try to pass the GPU through to Windows, all it sees is a Microsoft Basic Display Adapter reporting code 43 and it freezes/crashes after a short time. Here are the details of my current configuration (I am running Arch Linux with a 4.1 series kernel, and the GPU is at 0000:01:00.0 and 0000:01:00.1):
Kernel Command Line: root=PARTUUID=668f3b99-fcf9-46fa-b9d1-59d3a1e31690 rw quiet ipv6.disable=1 intel_iommu=on iommu=pt intremap=no_x2apic_optout
$ dmesg | grep -e IOMMU -e DMAR
[ 0.000000] ACPI: DMAR 0x000000005C4A2970 0000D4 (v01 ALASKA A M I 00000001 INTL 20091013)
[ 0.000000] Intel-IOMMU: enabled
[ 0.060166] dmar: IOMMU 0: reg_base_addr fbffd000 ver 1:0 cap d2008c10ef0466 ecap f0205b
[ 0.060171] dmar: IOMMU 1: reg_base_addr fbffc000 ver 1:0 cap d2078c106f0466 ecap f020df
[ 0.060175] IOAPIC id 8 under DRHD base 0xfbffc000 IOMMU 1
[ 0.060176] IOAPIC id 9 under DRHD base 0xfbffc000 IOMMU 1
[ 0.713630] IOMMU: dmar0 using Queued invalidation
[ 0.713631] IOMMU: dmar1 using Queued invalidation
[ 0.713634] IOMMU: Setting RMRR:
[ 0.713641] IOMMU: Setting identity map for device 0000:00:14.0 [0x5ce35000 - 0x5ce43fff]
[ 0.713648] IOMMU: Setting identity map for device 0000:00:1a.0 [0x5ce35000 - 0x5ce43fff]
[ 0.713653] IOMMU: Setting identity map for device 0000:00:1d.0 [0x5ce35000 - 0x5ce43fff]
[ 0.713657] IOMMU: Setting identity map for device 0000:05:00.0 [0x5ce35000 - 0x5ce43fff]
[ 0.713665] IOMMU: Prepare 0-16MiB unity mapping for LPC
[ 0.713668] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
$ dmesg | grep -i vfio
[ 0.759175] VFIO - User Level meta-driver version: 0.3
[ 0.779238] vfio_pci: add [1002:67b1[ffff:ffff]] class 0x000000/00000000
[ 0.809298] vfio_pci: add [1002:aac8[ffff:ffff]] class 0x000000/00000000
[114958.641595] vfio-pci 0000:01:00.0: enabling device (0100 -> 0103)
[114958.641708] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x19@0x270
[114958.641713] vfio_ecap_init: 0000:01:00.0 hiding ecap 0x1b@0x2d0
$ find /sys/kernel/iommu_groups/ -type l
/sys/kernel/iommu_groups/0/devices/0000:ff:0b.0
/sys/kernel/iommu_groups/0/devices/0000:ff:0b.1
/sys/kernel/iommu_groups/0/devices/0000:ff:0b.2
/sys/kernel/iommu_groups/1/devices/0000:ff:0c.0
/sys/kernel/iommu_groups/1/devices/0000:ff:0c.1
/sys/kernel/iommu_groups/1/devices/0000:ff:0c.2
/sys/kernel/iommu_groups/1/devices/0000:ff:0c.3
/sys/kernel/iommu_groups/1/devices/0000:ff:0c.4
/sys/kernel/iommu_groups/1/devices/0000:ff:0c.5
/sys/kernel/iommu_groups/2/devices/0000:ff:0f.0
/sys/kernel/iommu_groups/2/devices/0000:ff:0f.1
/sys/kernel/iommu_groups/2/devices/0000:ff:0f.4
/sys/kernel/iommu_groups/2/devices/0000:ff:0f.5
/sys/kernel/iommu_groups/2/devices/0000:ff:0f.6
/sys/kernel/iommu_groups/3/devices/0000:ff:10.0
/sys/kernel/iommu_groups/3/devices/0000:ff:10.1
/sys/kernel/iommu_groups/3/devices/0000:ff:10.5
/sys/kernel/iommu_groups/3/devices/0000:ff:10.6
/sys/kernel/iommu_groups/3/devices/0000:ff:10.7
/sys/kernel/iommu_groups/4/devices/0000:ff:12.0
/sys/kernel/iommu_groups/4/devices/0000:ff:12.1
/sys/kernel/iommu_groups/5/devices/0000:ff:13.0
/sys/kernel/iommu_groups/5/devices/0000:ff:13.1
/sys/kernel/iommu_groups/5/devices/0000:ff:13.2
/sys/kernel/iommu_groups/5/devices/0000:ff:13.3
/sys/kernel/iommu_groups/5/devices/0000:ff:13.4
/sys/kernel/iommu_groups/5/devices/0000:ff:13.5
/sys/kernel/iommu_groups/5/devices/0000:ff:13.6
/sys/kernel/iommu_groups/5/devices/0000:ff:13.7
/sys/kernel/iommu_groups/6/devices/0000:ff:14.0
/sys/kernel/iommu_groups/6/devices/0000:ff:14.1
/sys/kernel/iommu_groups/6/devices/0000:ff:14.2
/sys/kernel/iommu_groups/6/devices/0000:ff:14.3
/sys/kernel/iommu_groups/6/devices/0000:ff:14.6
/sys/kernel/iommu_groups/6/devices/0000:ff:14.7
/sys/kernel/iommu_groups/7/devices/0000:ff:15.0
/sys/kernel/iommu_groups/7/devices/0000:ff:15.1
/sys/kernel/iommu_groups/7/devices/0000:ff:15.2
/sys/kernel/iommu_groups/7/devices/0000:ff:15.3
/sys/kernel/iommu_groups/8/devices/0000:ff:16.0
/sys/kernel/iommu_groups/8/devices/0000:ff:16.6
/sys/kernel/iommu_groups/8/devices/0000:ff:16.7
/sys/kernel/iommu_groups/9/devices/0000:ff:17.0
/sys/kernel/iommu_groups/9/devices/0000:ff:17.4
/sys/kernel/iommu_groups/9/devices/0000:ff:17.5
/sys/kernel/iommu_groups/9/devices/0000:ff:17.6
/sys/kernel/iommu_groups/9/devices/0000:ff:17.7
/sys/kernel/iommu_groups/10/devices/0000:ff:1e.0
/sys/kernel/iommu_groups/10/devices/0000:ff:1e.1
/sys/kernel/iommu_groups/10/devices/0000:ff:1e.2
/sys/kernel/iommu_groups/10/devices/0000:ff:1e.3
/sys/kernel/iommu_groups/10/devices/0000:ff:1e.4
/sys/kernel/iommu_groups/11/devices/0000:ff:1f.0
/sys/kernel/iommu_groups/11/devices/0000:ff:1f.2
/sys/kernel/iommu_groups/12/devices/0000:00:00.0
/sys/kernel/iommu_groups/13/devices/0000:00:02.0
/sys/kernel/iommu_groups/14/devices/0000:00:03.0
/sys/kernel/iommu_groups/15/devices/0000:00:05.0
/sys/kernel/iommu_groups/15/devices/0000:00:05.1
/sys/kernel/iommu_groups/15/devices/0000:00:05.2
/sys/kernel/iommu_groups/15/devices/0000:00:05.4
/sys/kernel/iommu_groups/16/devices/0000:00:11.0
/sys/kernel/iommu_groups/16/devices/0000:00:11.4
/sys/kernel/iommu_groups/17/devices/0000:00:14.0
/sys/kernel/iommu_groups/18/devices/0000:00:16.0
/sys/kernel/iommu_groups/19/devices/0000:00:19.0
/sys/kernel/iommu_groups/20/devices/0000:00:1a.0
/sys/kernel/iommu_groups/21/devices/0000:00:1b.0
/sys/kernel/iommu_groups/22/devices/0000:00:1c.0
/sys/kernel/iommu_groups/23/devices/0000:00:1c.2
/sys/kernel/iommu_groups/24/devices/0000:00:1c.4
/sys/kernel/iommu_groups/25/devices/0000:00:1d.0
/sys/kernel/iommu_groups/26/devices/0000:00:1f.0
/sys/kernel/iommu_groups/26/devices/0000:00:1f.2
/sys/kernel/iommu_groups/26/devices/0000:00:1f.3
/sys/kernel/iommu_groups/27/devices/0000:01:00.0
/sys/kernel/iommu_groups/27/devices/0000:01:00.1
/sys/kernel/iommu_groups/28/devices/0000:02:00.0
/sys/kernel/iommu_groups/28/devices/0000:02:00.1
/sys/kernel/iommu_groups/29/devices/0000:04:00.0
/sys/kernel/iommu_groups/30/devices/0000:05:00.0
$ ls -l /dev/vfio
total 0
crw------- 1 root root 251, 0 Nov 21 23:56 27
crw-rw-rw- 1 root root 10, 196 Nov 21 23:56 vfio
Can anyone spot the thing I'm doing wrong? Thank you.
My setup is a new Skylake system. Asus Z170-A, i7 6700K, 16GB Corsair DDR4-2666, and a 250GB 850 EVO. I am using the onboard graphics and audio for Fedora, and passing the MSI GTX 970 to the VM.
I think the VM was "sharing" the audio with the host, and it was setup as ICH6 in virt-manager. I tried changing it to all the different options, but nothing brought the sound back. The only way I get sound is if I physically add the onboard sound to the VM., which disables it in the host when the guest is running. Since I can't (or shouldn't) turn the VM off that severely limits my host. Basically defeats the point of having a VM at all, since I have to (or should) reboot after shutting the VM down.
I put a simple PCI sound card in and attempted to pass that through, but it gave errors. I think I have to go through the same process of disabling it in the host before passing it through.
I'll read though the thread you linked to.
You do need to go through the same process and isolate it from the host system, after that it should work fine, as far as shutting down the KVM you can, it's a matter of preference, as I said it can cause instability in the host and cause you to reboot the host, it shouldn't do that often (but can) and because of the nature of Windows it does have to be shut down or rebooted don't let that bother you. I mentioned it so you were aware it may happen and to not be alarmed that something was wrong with your configuration or hardware....it's at this point normal on some systems, but will get better in the future.
Yesterday I had to reboot my KVM at least 6 times trying to resolve video driver issues, it never caused a problem in the host for me but on other days it has....it's no big deal just be aware it can happen.
Code 43 is odd to see passing a AMD GPU, you normally see that error when passing a Nvidia GPU because of the gimped driver stack that Nvidia supplies, I'd ask which driver version your trying to use for the AMD card, and what is your secondary GPU you are using for your host (Linux) system. I think the current AMD driver I'm using in the KVM is 15.11 and to be honest it's a little flaky on my system.
Somehow the Windows VM nuked itself overnight.
I turned the monitor off (because no matter what I do it won't turn the monitor off itself), let the host turn it's own monitor off, and went to bed. This morning I turned the Windows VM monitor back on and nothing happened. I forced off the VM and restarted. Same thing. It starts to boot, then the monitor goes to sleep and I get a black screen with a single, solid cursor in the console.
Every few boot attempts I get into recovery. But no matter what I try it either says the drive is locked, or it's read only, or it doesn't exist.
It's looking like I am going to have to reinstall and re set up my Windows VM.
Like blanger said, it's strange for an AMD setup to have the code 43 error. I have heard that the newer AMD drivers are pretty flaky, so it may be that.
I would go through all the steps you went through to see if you missed something. If not, just to try it, I'd remove the lines in the config file so the VM doesn't know it's actually a VM. You have to do this to get an Nvidia card's drivers to load, but it may be worth trying in your case.
Sound like the issue I've been having with the new AMD drivers I'm using, when I installed the new catalyst software it also installed some AMD game optimization software that runs in the tray at start-up, I've made the mistake twice of letting it update when it has prompted me about a new version and each time when rebooting it hangs the KVM, it will post, but hangs on the Windows loading screen or a black screen. I then have to kill the KVM, start it back up, then after POST hit the F8 key a few times to get a Windows boot menu, start in safe mode, kill the AMD card in device manager, then reboot and it will use the default Windows card, re-install the AMD drivers, reboot and everything is back to normal.
Like I said this has happen to me twice, and it's all because I'm looking for better graphic support for Fallout 4, if it wasn't for that I'd never update the drivers at all because every other game I have runs great, and it's not that FO4 doesn't because it does I'm just looking for a little bit more...lol but I still have managed to log almost 50 hours on the game running in the KVM....good times!
So did you give the KVM it's own HD or are you using drive space configured in QEMU / vert-manager that is shared by the host file system? I had a issue on some of the test KVMs that the drive space allocated by QEMU wasn't big enough and Windows couldn't create a swap file, it had similar prompts about the drive being locked or being read only.
Thanks, I'll try putting KVM in the hidden setting like you would with an Nvidia GPU. I can't even get to the point to install the drivers, the system runs for a few minutes then freezes or crashes and reboots.
I did not give the VM a hard drive, I made a raw disk file. It's 120GB, so I don't think it ran out of space.
At this point I have no idea what happened. I can get into Automatic Recovery. When I go to Troubleshoot, then Refresh My PC I get "The drive where Windows is installed is locked. Unlock the drive and try again." If I try to Reset My PC I get "Unable to reset your PC. A required drive partition is missing."
I don't know why it can't see the partition, or why it's "locked."
The same thing happens in the command prompt. It's either missing or locked.
Huh....that's weird, I did most of my early tests with a 40g allocation which is way too small to run Windows and install any programs unless the programs are really small, but it let me test my configuration and tweak it, about the 4th or 5th test KVM (I did all of this over the span of about a month or so last winter) I gave the KVM it's own 1tb hard drive which is what I use now. I'm on my 7th KVM or what I like to call my testing but I've been running this configuration since late July, some time this winter I'll create #8 which will have the added sound card and two R9 270's in crossfire, I'm hoping that will be the last one and I'll be good to go.
But that's never how that goes because Fedora will update to ver 23 after the first of the year and that will change the kernel and of course that will probably break something, but I'm optimistic it won't be too bad. I really like this setup it has been a great way to use Linux as a daily driver but yet keep Windows close and handy to game on.
Hopefully you'll get it sorted out, if I can help just ask.
I guess I've been lucky so far with my kernel updates, my Windows 10 VM is chugging along just fine! Heck I even updated my Nvidia drivers to the newest last night, still going well! Running a 780 Ti in the VM, added the kvm=hidden option and it's worked since day 1. Currently running linux-git (4.4rc1, compiled from git from I think Thursday or Friday last week) but I started with 4.3rc7, and even prior to that 4.2.3.
1 Like
I spent many months tweaking obscure boot parameters to try to reduce distortion in KVM guest audio and it turned out to be quite simple to fix. I did need some hardware however. This is what worked for me:
- Pass in a USB controller (as a PCI device rather than individual USB devices) to the guest.
- Run a USB DAC/soundcard off of the controller for dedicated guest audio.
- Use AMD or otherwise don't use the proprietary Nvidia drivers. The paravirtualization features that need to be disabled to run proprietary Nvidia drivers introduces noticeable clipping/popping into guest audio even while running a highend USB DAC with async/adaptive reclocking.
1 and 2 will probably get you to 90%. 3 may only be annoying if listening to music. I run a decently high end headphone setup from the guest now and hear no distortion.
1 Like