[fedora-virt] Issues with VGA passthrough using KVM and VFIO

Alex Williamson alex.williamson at redhat.com
Fri Dec 20 17:28:42 UTC 2013


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



More information about the virt mailing list