Sorry, hit save before I was finished...

I am trying to run a Qemu virtual machine using kvm/iommu/vfio/pci-stub with a discreet nVidia GTX-650 bound using vfio, and whenever I launch the virtual machine, I get the following error:

[drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt

and the VM fails to fully launch.

If I apply the patch attached as i915.patch, the VM launches fine, but I lose hardware acceleration as my graphics driver does not load and the Gallium GLX renderer takes over instead of Mesa DRI.

I have attached my dmesg with drm.debug=0xe set. One is before I launch the VM, and the other is after. I have also included (system-data.txt) the output of inxi -F and vainfo.

Created attachment 92454 [details]
dmesg after VM launch

Created attachment 92455 [details] [review]
Patch used to overcome VM launch failure

Created attachment 92456 [details]
My ssystem information

Created attachment 92464 [details]
system information

Didn't realize the output had color codes. This is easier to read.

Created attachment 92467 [details]
dmesg from kernel 3.13.0 with attached i915 patch

This is my dmesg output with a Qemu VM running on a successfully vfio bound NVidia card. I get no errors but I lose hardware acceleration on my main graphics card (integrated intel). Inxi and vainfo report:

$ inxi -Gx
Graphics:  Card-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0 
           Card-2: NVIDIA GK107 [GeForce GTX 650] bus-ID: 01:00.0 
           X.Org: 1.14.5 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@59.9hz 
           GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.3, 256 bits) GLX Version: 2.1 Mesa 9.2.1 Direct Rendering: Yes

*************************************************

$ vainfo
libva info: VA-API version 0.34.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
vaInitialize failed with error code -1 (unknown libva error),exit

VGA arbitration. Shudder. I tried to come up with a way to make it work somehow, and I apparently failed. I'm not going to try again any time soon.

Here's what Daniel had to say when he reverted a bunch of VGA arbiter changes from the driver. You can follow the link to my stop_machine hack.

commit ebff5fa9d545574324095d9c6a3cb80c9157abc5
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Oct 11 15:12:04 2013 +1000

    Revert "i915: Update VGA arbiter support for newer devices"
    
    This reverts commit 81b5c7bc8de3e6f63419139c2fc91bf81dea8a7d.
    
    Adding drm/i915 into the vga arbiter chain means that X (in a piece of
    well-meant paranoia) will do a get/put on the vga decoding around
    _every_ accel call down into the ddx. Which results in some nice
    performance disasters [1]. This really breaks userspace, by disabling
    DRI for everyone, and stops OpenGL from working, this isn't limited
    to just the i915 but both the integrated and discrete GPUs on
    multi-gpu systems, in other words this causes untold worlds of pain,
    
    Ville tried to come up with a Great Hack to fiddle the required VGA
    I/O ops behind everyone's back using stop_machine, but that didn't
    really work out [2]. Given that we're fairly late in the -rc stage for
    such games let's just revert this all.
    
    One thing we might want to keep is to delay the disabling of the vga
    decoding until the fbdev emulation and the fbcon screen is set up. If
    we kill vga mem decoding beforehand fbcon can end up with a white
    square in the top-left corner it tried to save from the vga memory for
    a seamless transition. And we have bug reports on older platforms
    which seem to match these symptoms.
    
    But again that's something to play around with in -next.
    
    References: [1] http://lists.x.org/archives/xorg-devel/2013-September/037763.html
    References: [2] http://www.spinics.net/lists/intel-gfx/msg34062.html
    Cc: Alex Williamson <alex.williamson@redhat.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

(In reply to comment #7)
> VGA arbitration. Shudder. I tried to come up with a way to make it work
> somehow, and I apparently failed. I'm not going to try again any time soon.
> 
> Here's what Daniel had to say when he reverted a bunch of VGA arbiter
> changes from the driver. You can follow the link to my stop_machine hack.
> 
> commit ebff5fa9d545574324095d9c6a3cb80c9157abc5
> Author: Dave Airlie <airlied@redhat.com>
> Date:   Fri Oct 11 15:12:04 2013 +1000
> 
>     Revert "i915: Update VGA arbiter support for newer devices"
>     
>     This reverts commit 81b5c7bc8de3e6f63419139c2fc91bf81dea8a7d.
>     
>     Adding drm/i915 into the vga arbiter chain means that X (in a piece of
>     well-meant paranoia) will do a get/put on the vga decoding around
>     _every_ accel call down into the ddx. Which results in some nice
>     performance disasters [1]. This really breaks userspace, by disabling
>     DRI for everyone, and stops OpenGL from working, this isn't limited
>     to just the i915 but both the integrated and discrete GPUs on
>     multi-gpu systems, in other words this causes untold worlds of pain,
>     
>     Ville tried to come up with a Great Hack to fiddle the required VGA
>     I/O ops behind everyone's back using stop_machine, but that didn't
>     really work out [2]. Given that we're fairly late in the -rc stage for
>     such games let's just revert this all.
>     
>     One thing we might want to keep is to delay the disabling of the vga
>     decoding until the fbdev emulation and the fbcon screen is set up. If
>     we kill vga mem decoding beforehand fbcon can end up with a white
>     square in the top-left corner it tried to save from the vga memory for
>     a seamless transition. And we have bug reports on older platforms
>     which seem to match these symptoms.
>     
>     But again that's something to play around with in -next.
>     
>     References: [1]
> http://lists.x.org/archives/xorg-devel/2013-September/037763.html
>     References: [2] http://www.spinics.net/lists/intel-gfx/msg34062.html
>     Cc: Alex Williamson <alex.williamson@redhat.com>
>     Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>     Cc: Chris Wilson <chris@chris-wilson.co.uk>
>     Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>     Signed-off-by: Dave Airlie <airlied@redhat.com>

Yeah, this issue seems to be a head-scratcher for you developer types, and I am not going to pretend to understand any of it. I just wanted something to work and it didn't, so I thought I would throw it out there for you guys to look at.

Oddly enough, I decided to switch to Arch Linux, and following the guidance found here:

https://bbs.archlinux.org/viewtopic.php?id=162768

I was able to get this to work flawlessly. On both Linux Mint and Arch I built the 3.13 kernel with the same patches (i915 & acs), and the same configuration file. Qemu and Seabios were built from git as well. On Arch it works fine. I can fully launch my Windows VM using the discreet nvidia card, and my onboard intel keeps my main desktop running with full hardware acceleration. The same setup in Linux Mint failed to deliver.

Thanks for the reply, and maybe sometime down the road you guys will crack this nut. Good luck!

Well not so much a head-scratcher but just requires real work to get resolved and not just an oddball patch.

And since we don't have anyone who really wants us to implement this I don't think well ever do it. So this needs someone else to dig into - there's regular threads every once in a while, but thus far no one stepped up to the challenge. Meanwhile it's more honest imo to just close this.