Next up would be Kernel, it sounds like... On Tue, Jan 26, 2016 at 8:27 AM, Ryan Flagler <[email protected]> wrote:
> Thanks for this info Will. Tried matching your qemu/libvirt versions and I > still get the driver crashes. I'm not sure what else to try. > > On Mon, Jan 25, 2016 at 9:20 PM Will Marler <[email protected]> wrote: > >> Hey Ryan, >> >> Here are the answers to your questions: >> >> 20:06:27 will ~% uname -a >> Linux haze 4.3.3-2-ARCH #1 SMP PREEMPT Wed Dec 23 20:09:18 CET 2015 >> x86_64 GNU/Linux >> 20:07:01 will ~% pacman -Q | egrep '^linux|^libvirt|^qemu' >> libvirt 1.3.1-1 >> libvirt-glib 0.2.2-1 >> libvirt-python 1.3.1-1 >> linux 4.3.3-2 >> linux-api-headers 4.1.4-1 >> linux-firmware 20151207.bbe4917-1 >> qemu 2.4.1-2 >> >> And here is the pastebin to my XML file: http://pastebin.com/nB3DPkEr >> >> As far as the guest drivers are concerned, they're the "GeForce Game >> Ready Driver" version 361.43. >> >> HTH! >> >> On Mon, Jan 25, 2016 at 10:12 AM, Ryan Flagler <[email protected]> >> wrote: >> >>> Thanks Will. Here is my info with the guest that crashes. >>> >>> Host OS Info >>> ubuntu - 14.04.03 >>> kernel - 3.19.0-47 >>> >>> virsh version >>> Compiled against library: libvirt 1.2.18 >>> Using library: libvirt 1.2.18 >>> Using API: QEMU 1.2.18 >>> Running hypervisor: QEMU 2.5.0 >>> >>> patches >>> I did not manually apply any patches to Qemu. Built directly from >>> source. >>> >>> Guest Info >>> Windows 10 >>> nVidia Graphics Driver 361.43 >>> >>> Guest Event Viewer Entry On Driver Crash >>> Source - nvlddmkm >>> Event ID - 14 >>> Info - \Device\Video3 CMDre 00000004 0000011c bad0011f 00000000 >>> 00d0011f >>> >>> Guest XML - Attached >>> >>> >>> On Mon, Jan 25, 2016 at 10:18 AM Will Marler <[email protected]> wrote: >>> >>>> On Mon, Jan 25, 2016 at 9:07 AM, Ryan Flagler <[email protected]> >>>> wrote: >>>> >>>>> Will, could you tell us the following? >>>>> >>>>> What Linux distribution on host? >>>>> >>>> Arch >>>> >>>>> What kernel are you using on host? >>>>> What libvirt version on host? >>>>> What qemu version on host? >>>>> >>>> Will have to check when I'm home from work & the kids are asnooze, but >>>> it's whatever's latest (and I'm not using the linux-vfio-lts kernel) >>>> >>>>> What OS on guest? >>>>> >>>> Windows 10. >>>> >>>>> What nvidia graphics driver version on guest? >>>>> >>>> Again, I'll have to check. But the latest or nearly latest. >>>> >>>>> My machines gpu driver crashes constantly and I'm trying to narrow >>>>> down why. Thanks! >>>>> >>>> How frustrating : (. I'll also get a pastebin of my XML for you, in >>>> case that will help. I've been running "stable" since mid 2015. I use the >>>> quotes because some things tripped me up (guest machine can't "sleep," can >>>> only power on & power off; when host machine goes to sleep with guest >>>> running, on host wake-up the guest is non-responsive and 100% CPU). >>>> >>>> Will >>>> >>>> >>>>> >>>>> On Mon, Jan 25, 2016, 10:02 AM Will Marler <[email protected]> wrote: >>>>> >>>>>> This is discussed in >>>>>> http://vfio.blogspot.com/2015/05/vfio-gpu-how-to-series-part-4-our-first.html. >>>>>> You have to do more than <kvm><hidden state='on'/></kvm>: >>>>>> >>>>>> "The GeForce card is nearly as easy, but we first need to work around >>>>>> some of the roadblocks Nvidia has put in place to prevent you from using >>>>>> the hardware you've purchased in the way that you desire (and by my >>>>>> reading >>>>>> conforms to the EULA for their software, but IANAL). For this step we >>>>>> again need to run virsh edit on the VM. Within the <features> section, >>>>>> remove everything between the <hyperv> tags, including the tags >>>>>> themselves. In their place add the following tags: >>>>>> >>>>>> <kvm> >>>>>> <hidden state='on'/> >>>>>> </kvm> >>>>>> >>>>>> Additionally, within the <clock> tag, find the timer named >>>>>> hypervclock, remove the line containing this tag completely. Save and >>>>>> exit >>>>>> the edit session." >>>>>> >>>>>> I can confirm it works, I've been getting a lot of mileage from my >>>>>> passed-through 750Ti lately since getting a Steam Link :-D. >>>>>> >>>>>> On Sun, Jan 24, 2016 at 7:32 AM, Ruben Felgenhauer < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> finally I had time to this again. I tried out virt-manager and after >>>>>>> a bit of playing around with it, it /somewhat/ worked: >>>>>>> >>>>>>> The machine is at least booting. I still have a standard vga card >>>>>>> enabled in the virt-manager config window. >>>>>>> After the machine has booted, I can see that the device gets >>>>>>> recognized as 750ti. >>>>>>> However, the gpu doesn't get used, because of 'Code 43'. >>>>>>> Code 43 is a generic error, so any idea what it could mean in this >>>>>>> case? >>>>>>> >>>>>>> Of course I added the <kvm><hidden state='on'/></kvm> lines at the >>>>>>> associated position. >>>>>>> >>>>>>> Best regards, >>>>>>> Ruben >>>>>>> >>>>>>> >>>>>>> Am 18.01.2016 um 22:27 schrieb Will Marler: >>>>>>> >>>>>>> I'm not sure what correct command-line syntax is. Have you tried >>>>>>> using libvirt and VirtManager to handle your VM rather than command >>>>>>> line, >>>>>>> and modifying the XML rather than the command line? I think that's >>>>>>> generally the preferred method these days (it's certainly easier from my >>>>>>> point of view, and the way I got my 750 Ti to pass through). >>>>>>> >>>>>>> On Mon, Jan 18, 2016 at 11:04 AM, Ruben Felgenhauer < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi, Alex! >>>>>>>> >>>>>>>> Thanks for your reply! >>>>>>>> My GPU indeed has a seperate audio device located at 01:00.1. >>>>>>>> >>>>>>>> However, just adding -device vfio-pci,host=01:00.1 doesn't seem to >>>>>>>> do the trick. >>>>>>>> Of course the corresponding device is already blacklisted and bound >>>>>>>> to vfio. >>>>>>>> >>>>>>>> The Debian Wiki entry about VGA passthrough ( >>>>>>>> <https://wiki.debian.org/VGAPassthrough> >>>>>>>> https://wiki.debian.org/VGAPassthrough) mentions QEMU arguments >>>>>>>> like "-device >>>>>>>> vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on,romfile=... >>>>>>>> -device vfio-pci,host=01:00.1,bus=pcie.0" which seems to address GPUs >>>>>>>> with >>>>>>>> audio devices, but if I try to do something similar, the buses 'root' >>>>>>>> and >>>>>>>> 'pcie' couldn't be found. Maybe I missed something very important? >>>>>>>> >>>>>>>> On the same article, it says that the "HDMI soundcard [...] needs >>>>>>>> to be unbound from its driver": >>>>>>>> # echo '0000:01:00.1' | sudo tee >>>>>>>> /sys/bus/pci/devices/0000:01:00.1/driver/unbind >>>>>>>> I figured the vfio-bind script from the Arch Linux Forum thread ( >>>>>>>> https://bbs.archlinux.org/viewtopic.php?id=162768) would do >>>>>>>> exactly this thing, so I didn't explicitly do so for the audio device. >>>>>>>> Is >>>>>>>> that okay? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Ruben >>>>>>>> >>>>>>>> >>>>>>>> Am 18.01.2016 um 08:31 schrieb Alexander Petrenz: >>>>>>>> >>>>>>>> Hi Ruben, >>>>>>>> >>>>>>>> I guess your 750ti also has some audio device. You should pass >>>>>>>> through this too. It should be something like 01:00.1. There are many >>>>>>>> command line examples you can find about that. >>>>>>>> Also I´m not quite sure, if you should remove the x-vga=on. >>>>>>>> >>>>>>>> Regards >>>>>>>> Alex >>>>>>>> >>>>>>>> On Sun, Jan 17, 2016 at 11:12 PM, Ruben Felgenhauer < >>>>>>>> <[email protected]> >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I am trying to pass my nVidia GTX 750ti to my QEMU guest. >>>>>>>>> >>>>>>>>> Problem is: After the QEMU monitor pops up, nothing happens. The >>>>>>>>> GPU's output is dead, and the vm won't be accessible via SSH anymore, >>>>>>>>> so >>>>>>>>> it's very likely that the VM isn't booting up at all. Also, there are >>>>>>>>> no >>>>>>>>> error messages from QEMU on the console whatsoever which makes >>>>>>>>> debugging it >>>>>>>>> especially hard. >>>>>>>>> >>>>>>>>> This is how I start the vm with normal vga emulation: >>>>>>>>> qemu-system-x86_64 -hda vm.ovl -boot c -enable-kvm -m 1024 -cpu >>>>>>>>> host,kvm=off -smp cores=4,threads=2 -redir tcp:5022::22 >>>>>>>>> Everything runs fine in this case. To do the passthrough, I add >>>>>>>>> this: >>>>>>>>> -device vfio-pci,host=01:00.0,multifunction=on,x-vga=on -vga none >>>>>>>>> This brings said problems with it. I also tried out multiple >>>>>>>>> different combinations of -device's arguments or even adding a >>>>>>>>> romfile for >>>>>>>>> the GPU, but none of these steps changed anything at all. >>>>>>>>> >>>>>>>>> Obviously, I am using a BIOS installation and I'm well-aware with >>>>>>>>> this bug: <https://bugzilla.kernel.org/show_bug.cgi?id=107561> >>>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=107561, but neither >>>>>>>>> using less RAM (as you can see I am using 1GB now) nor switching to an >>>>>>>>> older Kernel changed anything about the problem. I have tried Kernel >>>>>>>>> 4.1.0 >>>>>>>>> and 4.3.0. >>>>>>>>> >>>>>>>>> Host is Debian testing with QEMU 2.5.0. >>>>>>>>> I tried both Debian and Windows 7 as a guest, but both are showing >>>>>>>>> exactly the same behaviour. >>>>>>>>> Mainboard is an ASUS Z87-PLUS. The 750ti is produced by ASUS >>>>>>>>> aswell. >>>>>>>>> >>>>>>>>> Any idea how I could get passthrough running? >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> vfio-users mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> vfio-users mailing list >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> vfio-users mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>>>> >>>>> >>
_______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
