On Fri, 2013-12-20 at 12:14 -0500, Stewart Adam wrote: > On 2013-12-20 12:06 AM, Alex Williamson wrote: > > On Thu, 2013-12-19 at 12:41 -0500, Stewart Adam wrote: > >> On 2013-12-19 10:19 AM, Alex Williamson wrote: > >>> On Thu, 2013-12-19 at 01:48 -0500, Stewart Adam wrote: > >>>> Hi, > >>>> > >>>> I am trying to get VGA passthrough working using KVM and VFIO like > >>>> described on this [1] thread and ran into some issues I was hoping > >>>> someone could shed some light on. I have tried various configurations, > >>>> but can't seem to get it working correctly. Either I get "Code 10" > >>>> device error in Windows, or I get a BSOD 0x00000116 (VIDEO_TDR_ ERROR: > >>>> attempt to reset the display driver and recover from a timeout failed) > >>>> when booting the machine after installing the Catalyst 3D drivers. > >>>> Other users on the Arch Linux forum have also reported similar issues. > >>>> > >>>> <cut> > >>> > >>> Hi Stewart, > >>> > >>> The "x" in the x-vga option is for eXperimental. It works in some > >>> cases, not others. The archlinux forum thread is the best place to > >>> either get help or commiserate with others having the same problem. The > >>> advice there is largely not distribution specific. The 0x116 BSOD is a > >>> common problem with assigned Radeon graphics, we don't have a solution > >>> yet. Also note that this work is still under development, for the > >>> current "state of the art" you need a 3.13-rc kernel and qemu.git, and > >>> you may need to patch in some Intel graphics fixes for VGA arbitration. > >>> Even then, I have no reason to suspect the 0x116 BSOD is fixed. More > >>> users seem to be having success with Nvidia cards, so if that's an > >>> option for you, it may be the quickest path to results. Thanks, > >>> > >>> Alex > >> > >> Hi Alex, > >> > >> Thanks for replying so quickly. Ironically, I normally buy nVidia and > >> purchased this Radeon card because I had read online they tend to do > >> passthrough better (with Xen at least)... I didn't have much luck when I > >> tried a Xen VM either though. I do have an nVidia card handy and will try > >> that later tonight. > >> > >> Would the VGA arbitration patches relate to the Code 10 errors? Also, I > >> will > >> try again with 3.13-rc later this week but should I use qemu-vfio.git or > >> qemu.git? > > > > Probably not related to the Code 10, but I'm no expert in Windows error > > codes. > > > >> I realize this is all bleeding edge and thank you for all of your work on > >> it. Is there anything I can do to help you debug the 0x116 problem? > > > > vfio has plenty of debug support for tracing accesses to the card, it > > simply needs to be turned on in the source file. The issue is > > identifying the problem among all the output. With a closed source > > guest and driver, and lack of hardware documentation, it's quite a lot > > of guesswork. > > > >> Lastly, out of curiosity - is the 0x116 error dependent on particular piece > >> of hardware or it's a problem with the emulation layer + certain GPUs? > > > > No idea. Thanks, > > > > Alex > > Hi Alex, > > Yesterday I did a bit more reading and based on your suggestions above, > recompiled rawhide kernel 3.13.0-0.rc4.git4.1.fc21 from Fedora's build > system with a few additional patches applied to fix the problematic > PCIE-to-PCI bridge mentioned in my original post as well as your patches for > the i915 VGA arbitration with Haswell. > > I then compiled QEMU from latest git with the NoSnoop patch applied, as I > checked 'lspci -vv' and my card was showing NoSnoop+. > > The combination worked perfectly, and I had my monitor displaying at 1080p > with Catalyst Control Center fully functional! > > When I have more time I'm going to apply the patches one at a time and also > try using QEMU 1.7.0 to see which changes, exactly, made the difference. > I'll post back once I have more info.
Great! The NoSnoop patch should not be necessary with 3.13-rc and qemu.git, we've taken a different approach with that upstream, it should be handled by: kernel: ec53500fae421e07c5d035918ca454a429732ef4 d96eb2c6f480769bff32054e78b964860dae4d56 e0f0bbc527f6e9c0261f1d16b2a0b47612b7f235 qemu: bf63839ffa2d0eebb1eb1706022f46e93b6fec08 5b49ab188ff0339aa3097ce7f5309f1306092f9e linux 3.12 + above + i915 patches and qemu 1.7 + above would hopefully work as well. Thanks, Alex _______________________________________________ virt mailing list virt@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/virt
