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

apoapo · 2013-05-17 21:58:13

nbhs wrote:

Unfortunately, no, your best bet at this point is fill a bug @ qemu-devel, if you're using my script to bind the devices, you could try doing it manually, only binding the gpu and the gpu_snd, but i dont think vfio will work if all the devices of the same group are not binded to it.

Yeah will try this again and will then see what I can do .Or I have to buy a PCIe 1x oder PCI VGA card for host xD

nbhs · 2013-05-17 22:05:18

This is how you can manually bind it:

echo "0000:07:00.0"  >  /sys/bus/pci/devices/0000\:07\:00.0/driver/unbind
echo 1002 6719 > /sys/bus/pci/drivers/vfio-pci/new_id

Last edited by nbhs (2013-05-17 22:05:30)

apoapo · 2013-05-17 22:12:03

nbhs wrote:

This is how you can manually bind it:

echo "0000:07:00.0"  >  /sys/bus/pci/devices/0000\:07\:00.0/driver/unbind
echo 1002 6719 > /sys/bus/pci/drivers/vfio-pci/new_id

Yepp thx, know this .

Tried to get VGA passthrough working some times ago with different hardware, XEN and kvm with pci-assign

Last edited by apoapo (2013-05-17 22:12:59)

nbhs · 2013-05-17 22:16:33

Well if pci-assign worked for you in the past, and it crashed after a guest reboot, you can try the eject method under radeon related problems, that worked for me when using pci-assign

apoapo · 2013-05-18 01:39:11

It seems to work really well with pci-assign.

Now I have the Intel GPU as host-GPU. Running with X without any problems.
I'm able to reboot the VM with ejecting the card before reboot / shutdown.
Perfomance seems good and till now i havn't got freezes.

I can't use q35. If i do, the system says, the graphic card could not be started, so I use this configuration for now:

qemu-system-x86_64 --enable-kvm -m 4096 -cpu host \
-smp 4,sockets=1,cores=4,threads=1 \
-device pci-assign,host=01:00.0 \
-device pci-assign,host=01:00.1 \
-drive file=/var/lib/libvirt/images/win-test.img

nbhs · 2013-05-18 01:49:20

apoapo wrote:

It seems to work really well with pci-assign.
Now I have the Intel GPU as host-GPU. Running with X without any problems.
I'm able to reboot the VM with ejecting the card before reboot / shutdown.
Perfomance seems good and till now i havn't got freezes.
I can't use q35. If i do, the system says, the graphic card could not be started, so I use this configuration for now:
qemu-system-x86_64 --enable-kvm -m 4096 -cpu host \
-smp 4,sockets=1,cores=4,threads=1 \
-device pci-assign,host=01:00.0 \
-device pci-assign,host=01:00.1 \
-drive file=/var/lib/libvirt/images/win-test.img 

Great!

You can do the ejecting automatically using a tool called deveject, i detailed this process under radeon related problems

apoapo · 2013-05-18 03:12:15

It is running really great!

The only thing is, that running the scripts automatically with gpedit.msc isn't working. If i try to use this, the system will freeze at next start, so I think the scripts will not be executed.
If I eject the vga card manually I can reboot (shutdown and start again) as often as I want. When rebooting, the System starts without vga-card, because they are still ejected, I think.

But the performance is stunning!

Tried a game (Project Cars), where CPU and GPU are utilized very much at same settings.
Windows 7 nativ: 58fps
Windows 7 VM: 60fps
I think the 2 fps come from the clean install/less programms running

Also testing with very high Settings of the game (With downsampling 9 =>5760x3600 Pixel resolution), I get ~same fps like native!

nbhs · 2013-05-18 03:16:47

Gratz, the script should work tho, run cmd.exe as admin and execute

 deveject.exe -EjectId:"PCI\VEN_1002&DEV_6719&SUBSYS_31221682&REV_00\4&184E0D10&0&00E0"

change pci\ven.... to match yours, its works the same as manually ejecting so there's prolly a typo somewhere

Last edited by nbhs (2013-05-18 03:17:55)

apoapo · 2013-05-18 03:21:39

nbhs wrote:

Gratz, the script should work tho, run cmd.exe as admin and execute
 deveject.exe -EjectId:"PCI\VEN_1002&DEV_6719&SUBSYS_31221682&REV_00\4&184E0D10&0&00E0"
change pci\ven.... to match yours, its works the same as manually ejecting so there's prolly a typo somewhere

yeah. running deveject.exe manually is running fine. Only if I want to run it automatically at shutdown (with dpedit.msc script) it isn't working.

nbhs · 2013-05-18 03:24:37

copy deveject.exe to C:\Windows\System32\deveject.exe and try again, you need to put the full path under "Script name" and the rest under "Script Parameters" -->
-EjectId:"PCI\VEN_1002&DEV_6719&SUBSYS_31221682&REV_00\4&184E0D10&0&00E0"

apoapo · 2013-05-18 03:26:01

tried it again... is working now.
Did the same, I did before... think it could be a typo
Thanks a lot.

nbhs · 2013-05-18 03:26:29

np, and gratz

shadey · 2013-05-19 07:19:50

apoapo wrote:

It seems to work really well with pci-assign.
Now I have the Intel GPU as host-GPU. Running with X without any problems.
I'm able to reboot the VM with ejecting the card before reboot / shutdown.
Perfomance seems good and till now i havn't got freezes.
I can't use q35. If i do, the system says, the graphic card could not be started, so I use this configuration for now:
qemu-system-x86_64 --enable-kvm -m 4096 -cpu host \
-smp 4,sockets=1,cores=4,threads=1 \
-device pci-assign,host=01:00.0 \
-device pci-assign,host=01:00.1 \
-drive file=/var/lib/libvirt/images/win-test.img 

Hi there!
We have the same motherboard and GPU and almost the same CPU. (I have 3770) It looks like we are both trying to achieve the same thing too! I want to use my Intel IGP as the primary Linux desktop with the Radeon passed through for windows gaming.

After following this thread and your conversation I have encountered the same problems that you had. I noticed that vfio grabbed the PCI Express root and I could not get the BIOS display on the pass'd thru card. I see that you were able to get that working with PCI Express as the Primary VGA device on the host hardware. I have seen this behavior elsewhere so I think it might be a hardware limitation on our boards. I have been playing with many different VM systems lately and I saw the same behaviour with VMware ESXi 5.0.0 - if I didn't have primary VGA set to PCI Express AND disabled intel IGP in the host bios then the passed through display would be blank. Before VMWare I tried VGA pass through on Virtualbox and I gave up on that because of the blank screen thing and kernel crashes (I was not aware trying the Primary VGA bios setting at that stage). My best success before KVM has been in Xen using qemu-upstream.

Thank you for your configuration, I used a similar command line and managed to boot straight into my installed Win7 partition that I had created using Xen the day before, passthrough working and all. Now that I understand more the inner workings of QEMU I realised that I don't even need Xen to achieve my goals. I think KVM is a neat way to accomplish what we are trying to do.

Are you planning to use virtio drivers for network, disk etc? Would be interested to hear if you have success with it.

Dear OP: Thank you for this thread! It is how I discovered Archlinux and now I am converted.

I am using qemu-1.5.0-rc3 built with the "seabios" branch from seabios.git

Last edited by shadey (2013-05-19 07:20:57)

nbhs · 2013-05-19 09:13:06

shadey wrote:

Dear OP: Thank you for this thread! It is how I discovered Archlinux and now I am converted.

Sweet i'm glad this is useful

nbhs · 2013-05-19 10:41:42

Even though this is a kvm thread, i wanna share some of my experiences with XEN, and how to get PRIMARY vga passthrough ( gfx_passthru = 1 ) on radeon cards.

Sooooo, this is basically what im doing, i'm passing through my secondary radeon ( 6950 ) card ( although you can also pass your primary card), as a primary vga (without cirrus emulated card), my usb3 ports, and my sata controller with my 2TB disk connected to it, using a DUET image ( see http://www.rodsbooks.com/bios2uefi/ ), booting windows server 2008 on UEFI Mode straight from the controller ( no emulated disk controller ), with a hacked xen to enable intremap on my broken Asus crosshair v formula ivrs table, using the XM toolstack.

This is the package i use, xen-4.1.5 based on xen-4.2.2 from AUR: xen.tar.gz

I commented out my hack @ line 37 because this might break working systems.

Once extracted you'll find a file called vgabios-pt.bin. That is the rom file for my 6950, you have to dump your card's rom or d/l it from http://www.techpowerup.com/vgabios/, and replace that file with yours.

AFTER you copy your rom, build xen, install it then enable the needed services:

systemctl enable xenstored
systemctl enable xend

Now you need to actually boot xen so we create a new file called 05_xen @ /etc/grub.d

nano -w /etc/grub.d/05_xen

The fist 2 lines:

#!/bin/sh
exec tail -n +3 $0

For the rest the easiest way and the only one i'll describe here is to copy an entry from you /boot/grub/grub.cfg file:

cat /boot/grub/grub.cfg

Now copy the first menuentry to 05_xen:

menuentry 'Arch GNU/Linux, with Linux....
{
....
....
}

Add this line on top of "echo 'Loading Linux core repo kernel .":

multiboot	/xen-4.1.5.gz

Modify "linux /vmlinuz-linux" to "module /vmlinuz-linux" and "initrd /initramfs-linux" to "module /initramfs-linux"

Make 05_xen executable

chmod +x /etc/grub.d/05_xen

Edit /etc/mkinitcpio.conf and include xen-pciback

MODULES="xen-pciback"

If you wish to bind a device on boot to pciback modify 05_xen like this:

module	/vmlinuz-linux root=/dev/mapper/system-root ro xen-pciback.passthrough=1 xen-pciback.permissive=1 xen-pciback.hide=(07:00.0)(07:00.1)

Update grub.cfg

grub-mkconfig -o /boot/grub/grub.cfg

Reboot and check everything is works

xm info | grep virt_caps

virt_caps              : hvm hvm_directio

After this point if everything is working i suggest you read the xen documentation on how to create a vm, this is my configuration:

kernel = "hvmloader"
builder='hvm'
memory = 8192
name = "hvm"
cpus = [ "2", "3", "4", "5", "6", "7" ]
vcpus = 6 
disk = [ 'file:/root/xen/images/duet.img,hda,w' ]
pci = [ '00:11.0', '04:00.0', '05:00.0', '06:00.0', '0000:07:00.*' ]
vif = [ 'bridge=br0' ]
gfx_passthru = 1
localtime = 1
xen_platform_pci = 1
pci_power_mgmt = 1
pci_msitranslate = 0
viridian = 1

How i got windows to boot from my sata controller using qemu-dm and DUET

Notice this line:

disk = [ 'file:/root/xen/images/duet.img,hda,w' ]

This is the duet image i've been writing about, its a 200MB image containing DUET and REFIND ( http://www.rodsbooks.com/refind )( also included is a efi driver dump of the controller for RAID mode (sb950), so you can boot on RAID but i havent experimented with it much )

Duet image here: Duet.img.zip

The boot sequence is like this ROMBIOS-->DUET-->WINDOWS.

Duet contains drivers for the controller in ahci mode, it finds the windows efi partition and boots from it.

Radeon xen primary passthrough on xen:

Duet with REFIND booting windows ( with gfx_passthu = 0 to take the screenshot ):

Last edited by nbhs (2013-05-21 08:04:18)

jgott · 2013-05-19 20:40:33

nbhs wrote:

This is the package i use, xen-4.1.5 based on xen-4.2.2 from AUR: xen.tar.gz

Did the Xen people break VGA passthrough in recent versions? I got the sense that they had because I couldn't ever get 4.2 or 4.3 unstable to work completely (several different problems kept coming up), and I see that you're using 4.1.

I know they had a recent security advisory that resulted in tightening up some things and making matters worse for AMD IOMMU users with broken BIOSes. Apparently the switch to xl broke some things too (see the first entry on this page). And the gfx_passthrough option isn't yet supported for the new qemu device model (the default in 4.3, I think).

My sense is that some of the work done early on to make VGA passthrough work in Xen hasn't kept up with many of the recent changes in the project.

nbhs · 2013-05-19 21:01:43

jgott wrote:

nbhs wrote:
This is the package i use, xen-4.1.5 based on xen-4.2.2 from AUR: xen.tar.gz
Did the Xen people break VGA passthrough in recent versions? I got the sense that they had because I couldn't ever get 4.2 or 4.3 unstable to work completely (several different problems kept coming up), and I see that you're using 4.1.
I know they had a recent security advisory that resulted in tightening up some things and making matters worse for AMD IOMMU users with broken BIOSes. Apparently the switch to xl broke some things too (see the first entry on this page). And the gfx_passthrough option isn't yet supported for the new qemu device model (the default in 4.3, I think).
My sense is that some of the work done early on to make VGA passthrough work in Xen hasn't kept up with many of the recent changes in the project.

Im using xen-4.1 not because xen-4.2+ broke anything, simply because the xl toolstack doesnt support resseting passthru'd devices, what you're refering about not working on broken ivrs tables is this: XSA-36
which is also applied on xen 4.1.5, so i had to hack the xen code to make it work, which can aslo be applied (well it has to be modified a little) to xen-4.2+ ( i tried, it worked)

Included in my build i attached said fix, i have no idea if it breaks working builds, but im sure it works in our boards.

xm dmesg

...
(XEN) IOAPIC[0]: apic_id 9, version 33, address 0xfec00000, GSI 0-23
(XEN) IOAPIC[1]: apic_id 10, version 33, address 0xfec20000, GSI 24-55
(XEN) Enabling APIC mode:  Flat.  Using 2 I/O APICs
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 4414.882 MHz processor.
(XEN) Initing memory sharing.
(XEN) AMD-Vi: IOMMU 0 Enabled.
(XEN) AMD-Vi: Enabling per-device vector maps
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
...

The other 2 patches included, is a patch to load the bios from your card from here: http://markmail.org/message/7gb7djbmlaxruaai, which is important if you wish to passthrough a host secondary vga device as primary and this patch: http://old-list-archives.xenproject.org … 00705.html, modified by Greg Wettstein (http://lists.xen.org/archives/html/xen- … 00009.html) which allows to passthrough radeon cards as primary devices on xen with a pvops kernel.

Last edited by nbhs (2013-05-19 21:42:05)

jelly · 2013-05-20 17:44:19

It would be nice if you converted your first post about the KVM pci passthrough to a wiki article. Anyway nice work, sadly I don't have a VT-d enabled computer

nbhs · 2013-05-20 21:45:15

jelly wrote:

It would be nice if you converted your first post about the KVM pci passthrough to a wiki article. Anyway nice work, sadly I don't have a VT-d enabled computer

I'm not sure since this is experimental, and the success rate depends on a lot of variables, so i believe a thread where users can share experiences and solutions is a better alternative for now.

dariocaruso · 2013-05-21 20:27:13

Hi!

I just read about vfio driver, and i'm looking if it's possible to use the secondary (or different) gpu AND plug separate displays to have a multi-seat server, with virtualized different indipendent guests. Can i realize this with vfio driver?

nbhs · 2013-05-21 22:23:32

dariocaruso wrote:

Hi!
I just read about vfio driver, and i'm looking if it's possible to use the secondary (or different) gpu AND plug separate displays to have a multi-seat server, with virtualized differentin dependentguests. Can i realize this with vfio driver?

Well yeah, this is exactly what we're doing, 1 gpu per OS ( or more ), my host linux has 1 GPU and 1 monitor and my windows VM has 1 GPU and 1 monitor, each independent, each with a different usb keyboard and mouse

dariocaruso · 2013-05-21 22:57:56

nbhs wrote:

dariocaruso wrote:
Hi!
I just read about vfio driver, and i'm looking if it's possible to use the secondary (or different) gpu AND plug separate displays to have a multi-seat server, with virtualized differentin dependentguests. Can i realize this with vfio driver?
Well yeah, this is exactly what we're doing, 1 gpu per OS ( or more ), my host linux has 1 GPU and 1 monitor and my windows VM has 1 GPU and 1 monitor, each independent, each with a different usb keyboard and mouse

it seems exactly what i'm looking for years! I want to put in the office a good one server and plug 3 or 4 workstation for administrate differents vm's! Please someone tell me if really i can use autocad with no lag on 2-3 guests at same time (of coourse with enough ram, gpu and all). For years followed and tested spice, but it was not good, like i want, to work confortably with cad/cam programs. Really a good chance to get an usable/0 lag application server for architects! I will start to build mine soon!

nbhs · 2013-05-21 23:00:03

dariocaruso wrote:

nbhs wrote:
dariocaruso wrote:
Hi!
I just read about vfio driver, and i'm looking if it's possible to use the secondary (or different) gpu AND plug separate displays to have a multi-seat server, with virtualized differentin dependentguests. Can i realize this with vfio driver?
Well yeah, this is exactly what we're doing, 1 gpu per OS ( or more ), my host linux has 1 GPU and 1 monitor and my windows VM has 1 GPU and 1 monitor, each independent, each with a different usb keyboard and mouse

it seems exactly what i'm looking for years! I want to put in the office a good one server and plug 3 or 4 workstation for administrate differents vm's! Please someone tell me if really i can use autocad with no lag on 2-3 guests at same time (of coourse with enough ram, gpu and all). For years followed and tested spice, but it was not good, like i want, to work confortably with cad/cam programs. Really a good chance to get an usable/0 lag application server for architects! I will start to build mine soon!

Well, i'm playing metro last light and bioshock infinite @ max settings with no lag, while i watch tv on my arch host, everything works like a dream.

powerhouse · 2013-05-22 03:11:01

@nbhs: This is a great tutorial - thanks!

@dariocaruso: VGA passthrough doesn't exactly replace Spice. The way it works is that you have multiple VGA cards in your PC which can support multiple VMs (one per VGA card). However, you may have a problem using this one PC for say 2-3 people since they would have to sit together very close, because of the limitations of the DVI or HDMI cables as well as the USB cables, all of which have a limitted length they support. There are extenders, though.

Other than that you should get good performance for CAD/CAM and two architects sitting opposite or next to each other (because of the length limit of the cables) should be able to work on one PC.

jgott · 2013-05-22 03:15:59

jgott wrote:

nbhs wrote:
Are you sure the kernel and qemu are patched?
Yes.

I figured out what was wrong! Turns out, it was all my fault. I built my own packages, and I was pulling in the wrong branch from the qemu-vfio git repository. When troubleshooting, I had tried the linux-mainline package posted here, but not the qemu one. Oops.

VGA reset now works perfectly every time! No more system crashes! Awesome!

Windows Experience Index:

Some useful information I've gleaned:

Input devices:
Basic usability is achievable by using '-usbdevice tablet -vga none' (without '-nographic', so the qemu window will still open) and making the qemu window fullscreen so it catches cursor and keyboard events.

Individual USB device passthrough is problematic for input devices, since at some point you need to tell the host to un-passthru the devices, and your input devices are in the guest. It might be possible to make this work (ssh from guest to host and unbind the input devices), but all the ways I could think of were pretty ugly.

I've had good results passing through an entire USB3 controller (on the motherboard but not part of the chipset). A PCI add-on card would probably work great too, if I had the slots for it. Passing through one of the chipset's USB2 controllers seemed to result in more headers/ports being assigned than I intended, and it was trickier to determine the PCI device->USB root hub->physical port mapping. Your results may vary.

Audio:
Emulated audio was stuttery. My best results were with QEMU_AUDIO_DRV=alsa and QEMU_AUDIO_TIMER_PERIOD=0. AC97 was better than HD Audio for me, although I had to manually download Realtek's AC97 driver and force it in Add New Hardware (Intel's AC97 driver caused a guest BSoD). I think the PCI IDs are slightly off and Windows doesn't recognize the AC97 device automatically.

I'm going to pass through a real sound card device for better audio (and lower CPU usage). Unfortunately, the chipset audio device is tied to other important devices, and the second video card covers up the only PCI slot I have, so I need to buy a PCI Express one.

Disk:
Use the Windows virtio drivers unless you want to pass through a real disk controller. This will increase performance quite a bit.

The default driver is virtio-blk, but the virtio-scsi driver is the only one where I could get Windows to enable TRIM. In Defrag, Windows shows a virtio-scsi disk as a 'thin provisioned disk', which essentially means it knows it's a VM disk device and will pass TRIM commands (intended for VM disk images, but should work for real SSDs as well).

TRIM isn't strictly necessary for VM images or SSDs, but without it, images will take up more space than is necessary and SSD performance will degrade over time.

My current qemu invocation:
In case this is useful to anyone. It's a little ugly right now, as I'm still in the process of figuring out the best way to configure the devices.

QEMU_AUDIO_DRV=alsa \
QEMU_AUDIO_TIMER_PERIOD=0 \
qemu-system-x86_64 -enable-kvm -name Windows8 \
 -M q35 -nodefconfig -readconfig /pool/KVM/Windows8/q35-chipset.cfg \
 -m 4096 -balloon none -mem-path /dev/hugepages \
 -rtc base=localtime \
 -cpu host -smp 8,sockets=1,cores=4,threads=2 \
 -bios /usr/share/qemu/bios.bin \
 -vga none \
 -device vfio-pci,host=02:00.0,bus=ich9-pcie-port-1,addr=0.0,multifunction=on,x-vga=on \
 -device vfio-pci,host=02:00.1,bus=ich9-pcie-port-1,addr=0.1 \
 -device virtio-scsi-pci,id=scsi \
 -drive id=ssd,if=none,format=raw,discard=on,cache=none,file=/dev/CorsairVG/Windows \
 -drive if=virtio,format=raw,discard=on,file=/pool/KVM/Windows8/WinData.ntfs.img \
 -drive id=cdrom,media=cdrom,format=raw,file=/dev/null \
 -device scsi-hd,drive=ssd \
 -device ide-cd,bus=ide.0,drive=cdrom \
 -device vfio-pci,host=06:00.0,bus=ich9-pcie-port-2 \
 -boot order=cd,menu=on \
 -net nic,model=virtio,macaddr=00:55:aa:00:00:01 -net bridge,br=vm_br \
 -soundhw hda,ac97 \
 -usbdevice tablet \
 >$LOG 2>$LOG

Arch Linux

#26 2013-05-17 21:58:13

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

#27 2013-05-17 22:05:18

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

#28 2013-05-17 22:12:03

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

#29 2013-05-17 22:16:33

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

#30 2013-05-18 01:39:11

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

#31 2013-05-18 01:49:20

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

#32 2013-05-18 03:12:15

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

#33 2013-05-18 03:16:47

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

#34 2013-05-18 03:21:39

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

#35 2013-05-18 03:24:37

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

#36 2013-05-18 03:26:01

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

#37 2013-05-18 03:26:29

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

#38 2013-05-19 07:19:50

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

#39 2013-05-19 09:13:06

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

#40 2013-05-19 10:41:42

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

#41 2013-05-19 20:40:33

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

#42 2013-05-19 21:01:43

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

#43 2013-05-20 17:44:19

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

#44 2013-05-20 21:45:15

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

#45 2013-05-21 20:27:13

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

#46 2013-05-21 22:23:32

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

#47 2013-05-21 22:57:56

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

#48 2013-05-21 23:00:03

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

#49 2013-05-22 03:11:01

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

#50 2013-05-22 03:15:59

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

Board footer