KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

nbhs · 2013-12-28 13:55:54

BulliteShot wrote:

By the way, the linux-mainline package provided in this topic doesn't have the kernel modules statically loaded by default. I had to change the config files manually and skip makepkg integrity check. I know you can enable them in the kernel config dialog but I can never find anything there. I don't understand why they wouldn't be enabled by default in the package since it's possible to do so?

They're built as modules, it shouldn't make any difference as far as i'm aware off

Last edited by nbhs (2013-12-28 13:58:44)

tuoni · 2013-12-28 14:54:07

techdude300 wrote:

xani wrote:
Here's my directory from which you can test that memory leak issues.
linux-mainline.tar.gz
Provide me with feedback if you have the same problem with seabios after reverting those patches.
Thanks so much! I can confirm that this does in fact seem to fix the issue. For some reason I was having trouble building it when i tried the first two times, but I got it to work on the 3rd try. All the memory the VM allocates is now returned back to the machine, so I no longer have to reboot the host. A very strange issue. Now all that's left on my end is to figure out sound.

I have finally gotten round to testing this this morning and can confirm it also fixed the problem for me. Thank you!

Flyser · 2013-12-29 15:51:43

Hey guys,
I have another success story for you

I almost gave up on getting vga passthrough to work on my system (Intel DH87RL, i7-4771, Intel graphics + GTX 660) due to error 43, but I just found that a bios setting was the solution.
My mainboard has a "fast boot" option, which prevents the gpus from getting initialized by the bios and leaves that task to the operating system or bootloader. Previously both gpus would show the bios splash screen and the bootloader, now the only the internal graphics shows the bootloader and the linux console. I also had to use the romfile setting to get *any* output at all, which is not neccessary anymore. Now everything is running smooth and windows 8.1 works like a charm (well it's still a crappy os, but you know what I mean ;-)).
I think this setting would be worth mentioning on the first post, as it might solve the issue for others as well.

A few words about my setup (in the hope that it will be useful for others with similar hardware):
kernel cmdline: only

intel_iommu=on

is needed
qemu cmdline:

qemu-system-x86_64 -name windows8.1 -enable-kvm -watchdog i6300esb -boot menu=on -localtime -machine type=q35,accel=kvm -cpu host -smp 8,cores=4,threads=2,sockets=1 -m 6144 -k de -monitor tcp:127.0.0.1:5702,server,nowait -balloon virtio -vga none -display none -bios /root/vt-d/qemu-git/pc-bios/bios.bin -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 -usb -device usb-host,vendorid=0x17ef,productid=0x6009 -netdev user,id=net.0 -device virtio-net-pci,netdev=net.0,mac=00:01:02:03:04:05 -drive id=disk1,file=/dev/sdd,if=none,index=0,media=disk -device virtio-blk-pci,drive=disk1,bootindex=1

software versions: qemu-1.7.50-git_e8092f7 and bundled seabios, linux 3.13-rc6 with i915 and memleak patches (3.12.6+patches did not work)

Now I can fine-tune my setup. Have you found a good solution to save power while the VM is shut down or not in use? I am running this on my 24/7 home server and having the nvidia card running without any power management permanently consumes about 20 Watts, which amounts to over 50€ electricity cost per year in my country.

Best regards,
Flyser

Last edited by Flyser (2014-01-03 23:44:57)

Jesse2004 · 2013-12-29 16:02:16

tuoni wrote:

Hi guys, I just registered to thank you all for your work - because of this thread, I have finally got KVM/QEMU VGA passthrough working on my GT660Ti.
My setup is i7-4770 / ASRock Z87 Extreme 4 / Nvidia GT660Ti, host OS is Debian x64, guest OS is Windows 7 x64, keyboard/mouse sharing with Synergy.
I had bought the processor/mobo combo specifically to try and do VGA passthrough and had been really struggling first with Xen and latterly with KVM until I found this thread - the information in the OP and the patches it links to have been invaluable.
Thanks once again, all.

Hi tuoni, could you please elaborate a little more on your software stack? Are you using Wheezy plus self-compiled kernel and qemu or Debian unstable or ... ?

Just thinking about buying a very similar set of gears as yours.

tuoni · 2013-12-30 22:12:20

Jesse2004 wrote:

tuoni wrote:
Hi guys, I just registered to thank you all for your work - because of this thread, I have finally got KVM/QEMU VGA passthrough working on my GT660Ti.
My setup is i7-4770 / ASRock Z87 Extreme 4 / Nvidia GT660Ti, host OS is Debian x64, guest OS is Windows 7 x64, keyboard/mouse sharing with Synergy.
I had bought the processor/mobo combo specifically to try and do VGA passthrough and had been really struggling first with Xen and latterly with KVM until I found this thread - the information in the OP and the patches it links to have been invaluable.
Thanks once again, all.
Hi tuoni, could you please elaborate a little more on your software stack? Are you using Wheezy plus self-compiled kernel and qemu or Debian unstable or ... ?
Just thinking about buying a very similar set of gears as yours.

Sure - I'm using Jessie, self-compiled kernel (3.13-rc5 with gcc, i915, mem-leak and acs patches) and qemu from git pull (with vfio patch). I'm pretty sure it would work just fine on Wheezy, though, as you need to build your own kernel and qemu anyway.

noctavian · 2014-01-01 11:36:35

Hi, I made a summary of the working hardware and software configurations mentioned in the thread:
Configs

I hope I got all of them right, but there might be some mistakes, feel free to correct them. I'm also going to try VGA passthrough with vfio in next days.

empie · 2014-01-01 13:19:12

Great job noctavian!

TripleSpeeder · 2014-01-02 00:26:38

xani, I can confirm that your kernel also fixes the memory problems for me. All mem is free'd when qemu exits :-)

syllopsium · 2014-01-02 01:59:40

Success! I haven't conducted a full cycle of tests yet, but it works with Windows 7 and 8 x64 once the NoSnoop patch is applied to aw's qemu-vfio.git. GPU BIOS file is required.I suspect normal qemu would be fine too. Some instability when fiddling around with configs. Please hold for a stable configuration..

The nosnoop patch is not required for a Linux guest to work correctly with passthrough. At the moment I'm using the qemu64 processor instead of 'host' inside qemu. Changing it to host creates bluescreens. This might change if installed from scratch - watch this space. I hadn't bothered applying the nosnoop patch before now as I thought it was only necessary for Nvidia cards.

Brief configuration : Debian Jessie (Arch worked for Linux passthrough too, but Arch is a little too fast moving a distro for my main system). Kernel 3.13.0-rc5 with ACS patch. qemu with nosnoop patch.
Hardware : Intel S3210SHLC server motherboard, passing through AMD HD6950 GPU. Host GPU : discrete Geforce 218.
Qemu config : qemu64 processor in use. It is absolutely necessary to supply the appropriate BIOS to the graphics card. Experimented with various ioh3420/PCIe root configurations, appears fine with both below the ioh.

The motherboard has a built in Matrox G200e, I'm hoping to pass this through to a different VM as it's a horribly slow chip. It appears in the same iommu group as the southbridge x4 PCIe slot (the only slot where a graphics card won't be slowed down to x1 speed by the 3210 chipset on this motherboard). This is why I've applied the ACS patch.

Now to experiment more and decide if I want to run a fairly full function Linux host with a Windows guest, or a barebones Linux host with passthrough for both Windows and Linux or BSD VMs..

Last edited by syllopsium (2014-01-02 02:00:31)

pascal257 · 2014-01-02 02:50:48

Haha, I was about to post this, but I could fix the error by modprobe vfio_iommu_type1. So if someone has a similar problem, that might help.
But I would still like to know:
I've compiled the kernel without changing the config. Should I enable the VFIO config settings or is that not necessary with the patches?

Edit: And another question: I'd like to run a media center through the integrated graphics. Is that feasible? Can I pci-stub the integrated graphics from Arch and run it to a VM or are there any known problems?

First of all this thread has been a great read so far. I first started VGA-Passthrough with esxi and besides several other problems that didn't actually work.
Unfortunately I couldn't get it running with KVM either, but I'm certain that it'll work.
That's my hardware:
ASRock Z87 Extreme6
Intel i7 4770 (Host running on integrated graphics)
AMD Radeon R9 290 (For Windows Host)
NVidia GT 630 (For OSX Host)
At the moment I am working on getting the R9 290 to run.
On the software side:
Linux home 3.13.0-2-mainline - Compiled from first post with pci-stub.ids=1002:67b1,1002:aac8 intel_iommu=on pcie_acs_override=downstream
QEMU emulator version 1.7.50 - Compiled from first post
pci-stub is grabbing the card correctly:
[ 0.920077] pci-stub: add 1002:67B1 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 0.920083] pci-stub 0000:01:00.0: claimed by stub
[ 0.920086] pci-stub: add 1002:AAC8 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 0.920090] pci-stub 0000:01:00.1: claimed by stub
But I'm getting this error running qemu-system-x86_64 -enable-kvm -M q35 -m 1024 -cpu host -smp 6,sockets=1,cores=6,threads=1 -bios /usr/share/qemu/bios.bin -vga none -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: No available IOMMU models
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to setup container for group 18
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 18
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized
Group 18 beeing the R9 290:
### Group 18 ###
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device aac8
I've compiled the kernel without changing the config. Should I enable the VFIO config settings or is that not necessary with the patches?

Last edited by pascal257 (2014-01-02 02:57:09)

TripleSpeeder · 2014-01-02 09:54:39

nbhs wrote:

AUDIO EMULATION:
To hear the sound from the vm on your host speakers you'll need to add this lines:
-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 
You might need to start qemu like this (using pulseaudio, to use a different driver change QEMU_AUDIO_DRV= variable):
QEMU_PA_SAMPLES=128 QEMU_AUDIO_DRV=pa qemu-system-x86_64...

With QEMU_PA_SAMPLES=128 the sound is horribly distorted here. Without this parameter it works fine though. @Op: What is the background of this setting?

BulliteShot · 2014-01-02 13:07:22

Edit: Nevermind. I can't re-produce the problem.

With that patched kernel to stop the memory leak I can confirm it works unless I use hugetlbfs. Using hugetlbfs causes the memory leak again.

Last edited by BulliteShot (2014-01-05 01:42:10)

nbhs · 2014-01-02 16:09:47

TripleSpeeder wrote:

nbhs wrote:
AUDIO EMULATION:
To hear the sound from the vm on your host speakers you'll need to add this lines:
-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 
You might need to start qemu like this (using pulseaudio, to use a different driver change QEMU_AUDIO_DRV= variable):
QEMU_PA_SAMPLES=128 QEMU_AUDIO_DRV=pa qemu-system-x86_64...
With QEMU_PA_SAMPLES=128 the sound is horribly distorted here. Without this parameter it works fine though. @Op: What is the background of this setting?

Trial and error, im using alsa now instead of pulse now though

DanaGoyette · 2014-01-03 04:13:52

EDIT: Upgrading qemu to the git version may have fixed this odd behavior -- but I still wonder how it was possible...
EDIT again: Nope, still broken -- it was the power cycle that made it work once.

Original post:

I've managed to get GPU passthrough to "work" on my system, but the behavior is quite odd.

Upon initial driver installation, the Radeon showed the desktop properly.
Unfortunately, at every guest boot thereafter (even after host reboot), the desktop starts with only the cursor visible.

If I start Narrator (win-R, 'narrator'), I can navigate the desktop blindly, and it seems like the desktop is working "perfectly".

Hardware:
* Xeon E3-1245v3
* SuperMicro X10SAT
* XFX HD 5750
* Asus Xonar DX (with EEPROM tweaked to call it a Xonar D1).
Video card was grabbed from e-waste pile at work; unknown condition, but works quite well in Windows native boot.

Software:
* Ubuntu 13.10
* Qemu 1.7.0 (Debian 1.7.0+dfsg-2ubuntu3)
* Kernel 3.13 + acs-override patch (set to IDs of Intel root ports).
* Guest is Windows 8.1, 64-bit. (Video drivers won't load with Windows 7.)

Extra notes:
* VM behaves approximately the same both in Q35 mode and in PIIX4 mode (two different VMs, same virtual disk).
* Host is booted in EFI boot mode, using Intel graphics. This hopefully helps avoid some Intel VGA register usage.
* Guest is given GPU via VFIO, but primary VGA is Cirrus.
* I'd use EFI mode for the guest if I had a supporting video card, and if qemu didn't hang when attempting EFI mode...

The group I'm passing through is Group 1.
I tweaked 'lsgroup.sh' to use lspci -nn (names and numbers) instead of just lspci:

### Group 0 ###
    00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller (rev 06)
### Group 1 ###
    00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
    00:01.1 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x8 Controller (rev 06)
    01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Juniper PRO [Radeon HD 5750]
    01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Juniper HDMI Audio [Radeon HD 5700 Series]
    02:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa)
    03:04.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio]
### Group 2 ###
    00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 Processor Integrated Graphics Controller (rev 06)
### Group 3 ###
    00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
### Group 4 ###
    00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
### Group 5 ###
    00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
    00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series Chipset Family KT Controller (rev 04)
### Group 6 ###
    00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 05)
### Group 8 ###
    00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
### Group 9 ###
    00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
### Group 10 ###
    00:1c.1 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #2 (rev d5)
    05:00.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
    06:01.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
    06:04.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
    06:05.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
    06:07.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
    06:09.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba)
    0a:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
    0b:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] (rev 01)
    0c:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01)
### Group 11 ###
    00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5)
### Group 12 ###
    00:1c.4 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 (rev d5)
### Group 13 ###
    00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
### Group 14 ###
    00:1f.0 ISA bridge: Intel Corporation C226 Series Chipset Family Server Advanced SKU LPC Controller (rev 05)
    00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
    00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
    00:1f.6 Signal processing controller: Intel Corporation 8 Series Chipset Family Thermal Management Controller (rev 05)
### Group 15 ###
    04:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
### Group 16 ###
    0d:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
root@server-linux:~# nano -w lsgroup.sh 
root@server-linux:~# ./lsgroup.sh 
### Group 0 ###
    00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller [8086:0c08] (rev 06)
### Group 1 ###
    00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
    00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x8 Controller [8086:0c05] (rev 06)
    01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper PRO [Radeon HD 5750] [1002:68be]
    01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper HDMI Audio [Radeon HD 5700 Series] [1002:aa58]
    02:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge [10b5:8112] (rev aa)
    03:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] [13f6:8788]
### Group 2 ###
    00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3 Processor Integrated Graphics Controller [8086:041a] (rev 06)
### Group 3 ###
    00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06)
### Group 4 ###
    00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05)
### Group 5 ###
    00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
    00:16.3 Serial controller [0700]: Intel Corporation 8 Series/C220 Series Chipset Family KT Controller [8086:8c3d] (rev 04)
### Group 6 ###
    00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I217-LM [8086:153a] (rev 05)
### Group 8 ###
    00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 05)
### Group 9 ###
    00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 [8086:8c10] (rev d5)
### Group 10 ###
    00:1c.1 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #2 [8086:8c12] (rev d5)
    05:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8606] (rev ba)
    06:01.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8606] (rev ba)
    06:04.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8606] (rev ba)
    06:05.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8606] (rev ba)
    06:07.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8606] (rev ba)
    06:09.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch [10b5:8606] (rev ba)
    0a:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller [1912:0014] (rev 03)
    0b:00.0 PCI bridge [0604]: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] [104c:823e] (rev 01)
    0c:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] [104c:823f] (rev 01)
### Group 11 ###
    00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 [8086:8c16] (rev d5)
### Group 12 ###
    00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 [8086:8c18] (rev d5)
### Group 13 ###
    00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 05)
### Group 14 ###
    00:1f.0 ISA bridge [0601]: Intel Corporation C226 Series Chipset Family Server Advanced SKU LPC Controller [8086:8c56] (rev 05)
    00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] (rev 05)
    00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 05)
    00:1f.6 Signal processing controller [1180]: Intel Corporation 8 Series Chipset Family Thermal Management Controller [8086:8c24] (rev 05)
### Group 15 ###
    04:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 01)
### Group 16 ###
    0d:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)

Last edited by DanaGoyette (2014-01-03 04:42:09)

ayc · 2014-01-03 07:57:35

I have VGA pass-through of an ATI card working fine. For another VM I'm trying to pass through an Intel C606 SAS/SATA controller which isn't going very well.

1) pci-stub grabs the controller on boot and vfio binds to it
2) pci-assign passthrough to an Ubuntu Linux works fine
3) vfio-pci to the same Ubuntu Linux fails with I/O errors from the driver
4) device in the guest is bound to a ioh3420 bridge in qemu
5) Neither pci-assign nor vfio-pci work under FreeBSD, which is the eventual goal for this VM

The device has FLR, so I think should work fine. From the host:

[root@vs ~]# lspci -vvvs 03:00.0
03:00.0 Serial Attached SCSI controller: Intel Corporation C606 chipset Dual 4-Port SATA/SAS Storage Control Unit (rev 06)
	Subsystem: Super Micro Computer Inc Device 0630
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 26
	Region 0: Memory at d18f8000 (64-bit, prefetchable) [size=32K]
	Region 2: Memory at d1000000 (64-bit, prefetchable) [size=8M]
	Region 4: I/O ports at 8100 [size=256]
	Region 5: I/O ports at 8000 [size=256]
	Capabilities: [98] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [c4] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 1024 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
       [snip]

In looking at the differences between dmesg on pci-assign vs vfio-pci, there's this when
using vfio.

pci 0000:01:00.0: no compatible bridge window for [mem 0xd1800000-0xe0ffffff 64bit pref

and later on

PCI: max bus depth: 1 pci_try_num: 2
 pci 0000:01:00.0: reg 164: [mem 0xd1800000-0xd1ffffff 64bit pref
 pci 0000:00:1c.0: BAR 14: assigned [mem 0xc0000000-0xcf7fffff
 pci 0000:01:00.0: reg 164: [mem 0xd1800000-0xd1ffffff 64bit pref
 pci 0000:01:00.0: reg 164: [mem 0xd1800000-0xd1ffffff 64bit pref
 pci 0000:01:00.0: BAR 7: assigned [mem 0xc0000000-0xcf7fffff 64bit pref
 pci 0000:01:00.0: BAR 7: error updating (0xc000000c != 0xd180000c)
 pci 0000:00:1c.0: PCI bridge to [bus 01-01
 pci 0000:00:1c.0:   bridge window [io  0xc000-0xcfff
 pci 0000:00:1c.0:   bridge window [mem 0xc0000000-0xcf7fffff
 pci 0000:00:1c.0:   bridge window [mem 0xfc000000-0xfcffffff 64bit pref
 pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7
 pci_bus 0000:00: resource 5 [io  0x0d00-0xffff
 pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff
 pci_bus 0000:00: resource 7 [mem 0xc0000000-0xfebfffff
 pci_bus 0000:01: resource 0 [io  0xc000-0xcfff
 pci_bus 0000:01: resource 1 [mem 0xc0000000-0xcf7fffff
 pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff 64bit pref

vs doing a pci_assign:

pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff
 pci 0000:00:1c.0: res[14
 pci 0000:00:1c.0: BAR 14: assigned [mem 0xc0000000-0xc03fffff
 pci 0000:00:1c.0: PCI bridge to [bus 01-01
 pci 0000:00:1c.0:   bridge window [io  0xc000-0xcfff
 Freeing initrd memory: 15736k freed
 pci 0000:00:1c.0:   bridge window [mem 0xc0000000-0xc03fffff
 pci 0000:00:1c.0:   bridge window [mem 0xfc000000-0xfcffffff 64bit pref
 pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7
 pci_bus 0000:00: resource 5 [io  0x0d00-0xffff
 pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff
 pci_bus 0000:00: resource 7 [mem 0xc0000000-0xfebfffff
 pci_bus 0000:01: resource 0 [io  0xc000-0xcfff
 pci_bus 0000:01: resource 1 [mem 0xc0000000-0xc03fffff
 pci_bus 0000:01: resource 2 [mem 0xfc000000-0xfcffffff 64bit pref

When I don't put this behind a bridge, the only difference is that when using vfio, I get this extra line:

 pci 0000:00:02.0: reg 164: [mem 0xd1800000-0xd1ffffff 64bit pref

which is not in there when using pci-assign.

Any thoughts on further debugging this?

...alan

syllopsium · 2014-01-03 19:18:46

What's the parent device for the C606 SAS controller on the host? Looking at the chipset diagram it seems to be hanging directly off the IOH?

It may be obvious, but have you tried passing through the controller without specifying the point to hang it off? i.e. device=vfiio-pci,host=nn:nn.n,id=<friendlyname>

ayc · 2014-01-03 20:43:37

syllopsium wrote:

What's the parent device for the C606 SAS controller on the host? Looking at the chipset diagram it seems to be hanging directly off the IOH?

It's a bit weird. From Intel's data sheet:

The Intel® C606, C608 Chipset SKUs contain a PCI Express* switch. The Intel® C606,
C608 Chipset SKUs contains a x4 uplink and a “virtual” switch port that serves as the
connection for the integrated MFD shown in Figure 5-2. Software will discover a virtual
switch port with an attached multi-function end point device. The PCI Express* switch
is compliant to the PCI Express Base specification 2.0.

and earlier it gives a rationale as to why they're doing this:

The purpose of the uplink port is to provide a direct path for the SAS
controllers, SGPIO used by the SAS controllers, and SMBus ports to the processor/
memory without having to be multiplexed onto the DMI bus and sharing bandwidth
with the rest of the component. The uplink port is not connected to the downstream
root ports

lspci gives:

             +-01.0-[01-03]----00.0-[02-03]----08.0-[03]----00.0  Intel Corporation C606 chipset Dual 4-Port SATA/SAS Storage Control Unit

so, it's the 0000:03:00 device that i'm passing through. this is not a straight-forward device passthrough, so i'm not too surprised i'm having troubles with it.

It may be obvious, but have you tried passing through the controller without specifying the point to hang it off? i.e. device=vfiio-pci,host=nn:nn.n,id=<friendlyname>

yes, no go.

Forgot to say, just upgraded to the mainline from the first post, kernel 3.13-rc5.

...alan

TripleSpeeder · 2014-01-04 08:05:13

@xani: Do you know exactly the root cause of the memory leak and how you fixed it in your kernel? Or are you unsure on the exact reason? It would be awesome if we get this fixed also in the main kernel sources :-) Or are you already in contact with kernel devs about this topic?

Last edited by TripleSpeeder (2014-01-04 08:05:28)

sbd · 2014-01-04 08:09:30

DanaGoyette wrote:

Upon initial driver installation, the Radeon showed the desktop properly.
Unfortunately, at every guest boot thereafter (even after host reboot), the desktop starts with only the cursor visible.
If I start Narrator (win-R, 'narrator'), I can navigate the desktop blindly, and it seems like the desktop is working "perfectly".

Probably because you have the Cirrus VGA card as the primary. That's being treated as the primary monitor, so all the desktop content is showing up there and not on the Radeon.

peaquino · 2014-01-04 10:40:22

I'd like to report sucess with my Radeon passthrough! It works flawlessly, but only on a second guest launch.

On first launch after I get screen corruption on any 3D operation in guest (even showing a search box in Chrome) and the guest becomes unusable with constant driver resets to a point, when it grinds to a halt. At that moment I get about ~1K of log entries similar to

sty 04 11:12:57 miner kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x000000007bc4c100 flags=0x0010]
sty 04 11:12:57 miner kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002

When I abort first launch of the quest with a monitor quit command during during guest BIOS initialisation, on a second launch I get the following errors in Qemu monitor:

qemu-system-x86_64: vfio_dma_map(0x7f4b93fbbd40, 0x0, 0xb0000000, 0x2aaac0000000) = -16 (Device or resource busy)                                                                  
qemu-system-x86_64: vfio_dma_map(0x7f4b93fbbd40, 0xc0000, 0xaff40000, 0x2aaac00c0000) = -16 (Device or resource busy)                                                              
qemu-system-x86_64: vfio_dma_map(0x7f4b93fbbd40, 0xc8000, 0xaff38000, 0x2aaac00c8000) = -16 (Device or resource busy)                                                              
qemu-system-x86_64: vfio_dma_map(0x7f4b93fbbd40, 0xd0000, 0xaff30000, 0x2aaac00d0000) = -16 (Device or resource busy)

and the following entries in the kernel log

sty 01 22:04:53 miner kernel: vfio_ecap_init: 0000:01:00.0 hiding ecap 0x1b@0x2d0                                                                                                  
sty 01 22:04:55 miner kernel: ------------[ cut here ]------------                                                                                                                 
sty 01 22:04:55 miner kernel: WARNING: CPU: 3 PID: 1012 at drivers/vfio/vfio_iommu_type1.c:685 vfio_dma_do_map+0x43c/0x838 [vfio_iommu_type1]()                                    
sty 01 22:04:55 miner kernel: Modules linked in: tun bridge stp llc bnep vfio_pci vfio_iommu_type1 vfio fuse ts2020 ds3000 dvb_usb_dw2102 kvm_amd kvm crc32_pclmul c...luetooth rc_
sty 01 22:04:55 miner kernel: CPU: 3 PID: 1012 Comm: qemu-system-x86 Not tainted 3.13.0-2-mainline #1                                                                              
sty 01 22:04:55 miner kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./FM2A85X Extreme6, BIOS P2.30 07/11/2013                                                 
sty 01 22:04:55 miner kernel:  0000000000000009 ffff8804311b9d20 ffffffff814ddc72 0000000000000000                                                                                 
sty 01 22:04:55 miner kernel:  ffff8804311b9d58 ffffffff8105f2ed 00000000fffffff0 00000000b0000000                                                                                 
sty 01 22:04:55 miner kernel:  00000000000b0000 00000000b0000000 0000000000000000 ffff8804311b9d68                                                                                 
sty 01 22:04:55 miner kernel: Call Trace:                                                                                                                                          
sty 01 22:04:55 miner kernel:  [<ffffffff814ddc72>] dump_stack+0x4d/0x6f                                                                                                           
sty 01 22:04:55 miner kernel:  [<ffffffff8105f2ed>] warn_slowpath_common+0x7d/0xa0                                                                                                 
sty 01 22:04:55 miner kernel:  [<ffffffff8105f3ca>] warn_slowpath_null+0x1a/0x20                                                                                                   
sty 01 22:04:55 miner kernel:  [<ffffffffa0ce9dec>] vfio_dma_do_map+0x43c/0x838 [vfio_iommu_type1]                                                                                 
sty 01 22:04:55 miner kernel:  [<ffffffffa0cea3f9>] vfio_iommu_type1_ioctl+0x211/0x288 [vfio_iommu_type1]                                                                          
sty 01 22:04:55 miner kernel:  [<ffffffffa0ce0e28>] vfio_fops_unl_ioctl+0x78/0x340 [vfio]                                                                                          
sty 01 22:04:55 miner kernel:  [<ffffffff811adfb8>] do_vfs_ioctl+0x2d8/0x4b0                                                                                                       
sty 01 22:04:55 miner kernel:  [<ffffffff811ae211>] SyS_ioctl+0x81/0xa0                                                                                                            
sty 01 22:04:55 miner kernel:  [<ffffffff814ebd2d>] system_call_fastpath+0x1a/0x1f                                                                                                 
sty 01 22:04:55 miner kernel: ---[ end trace 53ac540a2e8783dc ]---                                                                                                                 
sty 01 22:04:56 miner kernel: ------------[ cut here ]------------

but the guest works flawlessly (even with reboots) with Catalyst drivers (Steam games work as expected).

Currently I'm using qemu-git package from AUR and linux-mainline from first page of this thread.

I hope this helps people struggling with Radeon passthrough.

Here is a link to a Qemu bug report: https://bugs.launchpad.net/qemu/+bug/1265998

MCon · 2014-01-04 18:22:33

I'm actually trying to follo this nice guide on a Debian Wheezy install.
I rebuilt a custom kernel:

$ uname -a
Linux black 3.13.0-rc6-customkernel #2 SMP Sat Jan 4 16:21:06 CET 2014 x86_64 GNU/Linux

VIRTIO is currently compiled into the kernel (no modules).

I also compiled qemu-git (NOT using Your scripts, obviously tied to ArchLinux, but a "normal" .configure -> make -> sudo make install cycle; here may be the problem!) and openqrm-community (again with plain make -> sudo make install).

Launching qemu-system-x86_64 ... (it's in a script) I see:

$ sudo ./start
VNC server running on `::1:5900'

Nothing happens on the GTX770 monitor and connecting to VNC I see:

compat_monitor0 console
QEMU 1.7.50 monitor - type 'help' for more information
(qemu)

Before I send my whole config is there something I should cross-check?
I'm pretty sure I gooofed somewhere badly.

Here comes config:

$ lspci
00:00.0 Host bridge: Intel Corporation Haswell DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Haswell PCI Express x16 Controller (rev 06)
00:01.1 PCI bridge: Intel Corporation Haswell PCI Express x8 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Haswell Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Haswell HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation Lynx Point USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation Lynx Point MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 04)
00:1a.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation Lynx Point High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #1 (rev d4)
00:1c.1 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #2 (rev d4)
00:1c.5 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #6 (rev d4)
00:1d.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Lynx Point LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation Lynx Point 6-port SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation Lynx Point SMBus Controller (rev 04)
02:00.0 VGA compatible controller: NVIDIA Corporation Device 1184 (rev a1)
02:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1)
04:00.0 Network controller: Atheros Communications Inc. AR9462 Wireless Network Adapter (rev 01)
05:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
$ lspci -n | grep ^02
02:00.0 0300: 10de:1184 (rev a1)
02:00.1 0403: 10de:0e0a (rev a1)
$ cat bind.sh 
sudo vfio-bind 0000:02:00.0 0000:02:00.1
$ cat start 
qemu-system-x86_64 -enable-kvm -M q35 -m 1024 -cpu host \
-smp 4,sockets=1,cores=2,threads=2 \
-bios /usr/local/share/qemu/bios.bin -vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=02:00.1,bus=root.1,addr=00.1

Thanks in advance
Mauro

BulliteShot · 2014-01-05 01:40:21

Has anyone got any working packages for pci-stub only? q35 performance is pretty poor for memory demanding games.

Val532 · 2014-01-05 02:51:46

Hi all,

I have some new information and I do not know who to share.

The probleme i found for pci passthougr of sata AsMedia 1062 :

[ 404.206866] dmar: DRHD: handling fault status reg 2
[ 404.206870] dmar: DMAR:[DMA Write] Request device [07:00.0] fault addr 2affdf000
[ 404.206870] DMAR:[fault reason 05] PTE Write access is not set
[ 404.206877] dmar: DRHD: handling fault status reg 2
[ 404.206879] dmar: DMAR:[DMA Read] Request device [07:00.0] fault addr 2affda000
[ 404.206879] DMAR:[fault reason 06] PTE Read access is not set

Is the same for Intel Z87 sata.

I can't use the Intel Sata with vfio because of ACS, ACS patch does not work for Intel Sata [00:1f.2] and when i use with pci_stub it's work only one time, when the VM reboot i have this error :

[ 1801.280862] dmar: DRHD: handling fault status reg 2
[ 1801.280866] dmar: DMAR:[DMA Read] Request device [00:1f.2] fault addr 2affdd000 
[ 1801.280866] DMAR:[fault reason 06] PTE Read access is not set

Where i can report this error in the hope of any boby correct this ?

Thanks.

DanaGoyette · 2014-01-05 05:21:30

Val532 wrote:

I can't use the Intel Sata with vfio because of ACS, ACS patch does not work for Intel Sata [00:1f.2]...

If you haven't already done so, try passing through the other devices in that group, such as:
00:1f.0 ISA bridge [0601]: Intel Corporation C226 Series Chipset Family Server Advanced SKU LPC Controller [8086:8c56] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 05)
00:1f.6 Signal processing controller [1180]: Intel Corporation 8 Series Chipset Family Thermal Management Controller [8086:8c24] (rev 05)

Alternately, these devices should be overridable via 'multifunction', or better, via device ID (in my case, it's id:8086:8c02).

sbd wrote:

Probably because you have the Cirrus VGA card as the primary. That's being treated as the primary monitor, so all the desktop content is showing up there and not on the Radeon.

I actually used Narrator to get the virtual machine's desktop to appear only on the ATI card, and not at all on the Cirrus. The ATI desktop was alive and "functional", but totally black.

I've rebuilt Qemu from git, and now it seems to be defaulting to pci-assign instead of VFIO. This works fine, aside from needing the "eject" workaround (which kicks the GPU into high-speed-fan mode).
In fact, now I'm thinking this may have something to do with that black desktop -- perhaps the black desktop is a result of NOT ejecting.
Time for more experimenting...

EDIT:
Okay, I tried switching back to vfio. No dice:
genirq: Flags mismatch irq 16. 00000000 (vfio-intx(0000:01:00.0)) vs. 00000080 (ehci_hcd:usb1)

Adding the EHCI controller (#2, oddly enough, not #1 as 'usb1' would seem to imply), seems to perhaps fix this.

If I add my sound card to the mix:
genirq: Flags mismatch irq 17. 00000000 (vfio-intx(0000:07:04.0)) vs. 00000000 (vfio-intx(0000:01:00.1))

How the heck is '00000000' a mismatch with '00000000'?

Last edited by DanaGoyette (2014-01-05 05:58:32)

cataphract · 2014-01-05 13:52:34

I tried this with Linux 3.12.6-1-ARCH, qemu 1.7.0-1 and seabios 1.7.3.1-2 without success.

I have this motherboard:

[    0.000000] DMI: Gigabyte Technology Co., Ltd. Z87MX-D3H/Z87MX-D3H-CF, BIOS F5 08/02/2013

a 4770 and Radeon 6950. Main display is connected to the IGP.

$ dmesg | grep pci-stub
[    0.000000] Command line: root=UUID=9dac92cf-60d1-4a6d-b9a4-066bb876c9ce ro intel_iommu=on modprobe.blacklist=radeon pci-stub.ids=1002:6719,1002:aa80 initrd=\initramfs-linux.img
[    0.000000] Kernel command line: root=UUID=9dac92cf-60d1-4a6d-b9a4-066bb876c9ce ro intel_iommu=on modprobe.blacklist=radeon pci-stub.ids=1002:6719,1002:aa80 initrd=\initramfs-linux.img
[    1.289177] pci-stub: add 1002:6719 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    1.289193] pci-stub 0000:01:00.0: claimed by stub
[    1.289197] pci-stub: add 1002:AA80 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    1.289201] pci-stub 0000:01:00.1: claimed by stub

The vfio-bind also works fine. I then tried this command line to run qemu:

qemu-system-x86_64 \
	-enable-kvm \
	-m 4096 \
	-drive file=win7.qcow2,if=ide \
	-drive file=/mnt/evo/Arquivo/Windows7_Pro_SP1_English_x64.iso,if=ide,media=cdrom \
	-bios /usr/share/qemu/bios.bin \
	-M q35 \
	-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
	-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on,romfile=XFX.HD6950.1024.110116_1.rom \
	-device vfio-pci,host=01:00.1,addr=0.1,bus=root.1 \
	-boot menu=on \
	-cpu host \
	-smp 3 \
	-nographic \
	-vga none

but I see nothing on the second display (connected via HDMI).

For some reason, I cannot boot linux-mainline or the modified linux-mainline posted on the front page. It can't find the root partition and I'm dropped to a shell where even my usb keyboard doesn't work. It's strange because I never had any problem with official kernel. I'm using refind.

Arch Linux

#951 2013-12-28 13:55:54

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#952 2013-12-28 14:54:07

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#953 2013-12-29 15:51:43

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#954 2013-12-29 16:02:16

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#955 2013-12-30 22:12:20

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#956 2014-01-01 11:36:35

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#957 2014-01-01 13:19:12

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#958 2014-01-02 00:26:38

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#959 2014-01-02 01:59:40

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#960 2014-01-02 02:50:48

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#961 2014-01-02 09:54:39

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#962 2014-01-02 13:07:22

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#963 2014-01-02 16:09:47

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#964 2014-01-03 04:13:52

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#965 2014-01-03 07:57:35

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#966 2014-01-03 19:18:46

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#967 2014-01-03 20:43:37

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#968 2014-01-04 08:05:13

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#969 2014-01-04 08:09:30

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#970 2014-01-04 10:40:22

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#971 2014-01-04 18:22:33

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#972 2014-01-05 01:40:21

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#973 2014-01-05 02:51:46

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#974 2014-01-05 05:21:30

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

#975 2014-01-05 13:52:34

Re: KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

Board footer