[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