Arch Linux

shawly

Member

Registered: 2014-05-24

Posts: 22

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

I finally figured out why OVMF isn't booting, it's because of q35!
Question is, how do I get it working with q35? Do I even need q35, do I have any advantages with q35 over i440fx? (sorry I'm quite new to qemu and I'm like Jon Snow.. I know nothing.)

Last edited by shawly (2014-06-01 15:32:54)

rabcor

Banned

Registered: 2013-02-09

Posts: 500

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

Quoting OP:

NOTE: -m q35 | Enable the new q35 emulated chipset, qemu defaults to the old i440fx chipset.
You should see a black qemu window on your main display, and seabios ouput on your monitor from your passthru'd card saying it cant find anything to boot.
Its important to use -M q35 which is the new qemu emulated intel chipset with pcie support,

Also, not sure how this is better but I posted the vfio-bind script elsewhere and someone told me I should improve it by making it like so:

#!/bin/sh 
 
modprobe vfio-pci 
 
for dev in "$@"; do 
    read -r vendor </sys/bus/pci/devices/$dev/vendor 
    read -r device </sys/bus/pci/devices/$dev/device 
    if [ -e /sys/bus/pci/devices/$dev/driver ]; then 
        echo $dev > /sys/bus/pci/devices/$dev/driver/unbind 
    fi 
    echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id 
done

Last edited by rabcor (2014-06-01 16:11:19)

---

Making Logitech G510 Work on Linux!

djbdayong

Member

Registered: 2014-05-01

Posts: 1

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

Hi,

I am yet another lurker that has found this thread invaluable in getting my setup working, a big thank you to nbhs, aw and indeed everyone!

Some details should they be useful to someone:

Motherboard: ASRock Fatal1ty z87 Killer
CPU: Intel Xeon E3-1245v3
Passthrough GPU: XFX Radeon R9 270X
Kernel: 3.14.4
Qemu: 2.0.0
Guest Firmware: Seabios, 1.7.5
Guest OS: Windows 8

Main motivations, aside from curiosity, were running my preferred OpenCL accelerated RAW converter and photo processing software without sacrificing the Linux desktop with dual boot. As well as some light gaming. For these purposes the setup runs wonderfully.

I installed more or less as per OP instructions and it went smoothly thanks to all of you trail blazers on this thread (Excuse any ignorance, I am still far from grasping the finer details of the moving parts):

1. Blacklisted passed GPU drivers on the host since it is only used when I run the guest.
2. Reproduced the colourful VGA arbitration issue and applying the OP i915 patch immediately solved it.
3. Was able to install virtio guest drivers during Windows 8 setup. Had to omit the OP qemu virtio controller for Windows to match the Red Hat drivers to the unknown virtio disk device. See the qemu command below for what I ended up with.
4. Windows 8 activated without any problems (wondering how sensitive it will be to future qemu/seabios upgrades ???)
5. Since I have all of my audio equipment connected to my host sound device + remote PA server and due to accounts of BSOD due to HDMI audio funny business, I decided to just install the AMD video driver and avoid as much extra Catalyst fluff as possible. So I did a custom install with HDMI audio device not passed to the guest. This went smoothly and no BSOD on reboot. For guest sound, I use an emulated sound device and qemu PA driver as per OP.
6. Installed synergy for keyboard/mouse sharing.

Qemu command line:

qemu-system-x86_64 \
-enable-kvm \
-M q35 \
-cpu host \
-m 12288 \
-smp 6,sockets=1,cores=3,threads=2 \
-bios ${PATH_BIOS} \
-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 \
-drive if=virtio,id=disk,file=${PATH_DISK_IMAGE},format=raw \
-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0

I'm happy to test new patches and otherwise provide more info.

thehighhat

Member

Registered: 2014-05-12

Posts: 5

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

So I had a working vga passthrough of nvidia gtx470 with a windows 8 guest.  I let the windows store upgrade to windows 8.1 update.  now, the guest will not start correct.  it always goes into automatic system repair and fails.  the refresh pc, reset pc options ask for windwos cd, but cannot detect it.  if i just let windows try to start, it shows nohing but a black screen.  then i have reboot the host becaues i cannot shutdown the guest cleanly.

any ideas why the 8.1 update breaks everything?

rabcor

Banned

Registered: 2013-02-09

Posts: 500

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

When I do

sudo chown rabcor /dev/vfio/13

In a desperate attempt to run the VM as user, I get a new error

qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x7f4b3a2cced0, 0x0, 0x80000000, 0x7f4a08000000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x7f4b3a2cced0, 0x100000000, 0x80000000, 0x7f4a88000000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: memory listener initialization failed for container
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to setup container for group 13
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 13
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized

I tried running

#ulimit -l  10485760

As root to allow the user to allocate that amount of memory to the VM as suggested somewhere on the net, but it had no effect on the error

Do I really just have to run it as root?

PS: Still can't solve that qemu is not finding the ahci.0 bus

#lspci | grep SATA
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode]

Last edited by rabcor (2014-06-02 05:15:36)

---

Making Logitech G510 Work on Linux!

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

http://www.linux-kvm.org/wiki/images/b/ … m-VFIO.pdf

Start on slide 21

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

rabcor

Banned

Registered: 2013-02-09

Posts: 500

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

Thanks, but still not working

chown rabcor /dev/vfio/13
chmod 660 /dev/vfio/vfio
chown rabcor /dev/vfio/vfio
ulimit -l 8409088

Note: I had to do chown user on vfio because it denied me permission after running chmod 660 on it.

Ran ulimit -l 8409088 for 8gigs ((8192 + 20) * 1024 as the pdf you linked suggested)

Still get

qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x7fe886977d80, 0x0, 0x80000000, 0x7fe750000000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x7fe886977d80, 0x100000000, 0x80000000, 0x7fe7d0000000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: memory listener initialization failed for container
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to setup container for group 13
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 13
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized

Last edited by rabcor (2014-06-02 06:38:52)

---

Making Logitech G510 Work on Linux!

trimm

Member

Registered: 2014-03-06

Posts: 31

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

Nvidia has filed a bug now regarding the hypervisor check.
https://forums.geforce.com/default/topi … 26-14-/36/

Hopefully they will fix it, I have some doubts though!

rabcor

Banned

Registered: 2013-02-09

Posts: 500

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

At least they know now that they're going to have to pick a side, with us or against us, and they know siding with their users is only going to make them look more cool.

From their perspective they should try to see that no workarounds (like the VGA_ARB patch) are needed to make this just work on AMD hardware (hell xen has been capable of it for a long time but when it comes to nvidia cards it was always a pain to make them work there) meaning this is a feature AMD is already offering and not fighting against like they are.

I guess we'll see in one of the next few nvidia driver updates what their reply is (i.e. they will either fix it or they will do something else to make our lives miserable)

---

Making Logitech G510 Work on Linux!

slis

Member

Registered: 2014-06-02

Posts: 127

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

hello there

amazin and long topic

hope someone can help me...

i got some problems... yesterday i managed to get passthrough running but performance was low... (DOTA2 native 120fps, in kvm 40-50fps, drops to 20fps sometimes jumps to 90fps

my config
i72600
Z77X-UD3H
host igpu
guest 560ti
jessie 13.4.4 + i915patch, acs and debug register

i am also interested in getting SLI running since i have 2 same cards, and is it possible to pass IGPU? so i can have hw video (quicksync) encode since 5xx series lack that and i can't stream 60fps

P.S.
what are proper patches,grub commands and kernel needed for my system?
do i need pci-stub, and vfio-bind, both?
can i pass it with pci-assign?

i can only reboot vm, after shutdown i must reboot host? is that normal? 
Thank you

Last edited by slis (2014-06-02 13:20:34)

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Thanks, but still not working

chown rabcor /dev/vfio/13
chmod 660 /dev/vfio/vfio
chown rabcor /dev/vfio/vfio
ulimit -l 8409088

Note: I had to do chown user on vfio because it denied me permission after running chmod 660 on it.

Ran ulimit -l 8409088 for 8gigs ((8192 + 20) * 1024 as the pdf you linked suggested)

Still get

qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x7fe886977d80, 0x0, 0x80000000, 0x7fe750000000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x7fe886977d80, 0x100000000, 0x80000000, 0x7fe7d0000000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: memory listener initialization failed for container
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to setup container for group 13
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 13
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized

As noted in the slides, an additional 20MB was sufficient for that example config, with an assigned NIC that has much, much less MMIO space.  If you want to make sure things are covered, add an extra 1G.  Also make sure you're setting ulimit in a way that transfers to the user process, 'sudo ulimit ...' is not sufficient.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

buraktamturk

Member

Registered: 2014-05-28

Posts: 13

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

I finally figured out why OVMF isn't booting, it's because of q35!
Question is, how do I get it working with q35? Do I even need q35, do I have any advantages with q35 over i440fx? (sorry I'm quite new to qemu and I'm like Jon Snow.. I know nothing.)

I changed my virtual machine configuration to q35 (had to change everything including pci, usb bus configs). Still OVMF does not come up to the monitor, thanks to you, i am now using seabios and q35 :-)

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Regarding Nvidia 337.88:

https://forums.geforce.com/default/topi … 3/#4232923

We fixed some hypervisor detection code that was breaking Hyper-V. It's possible that fix may be preventing GeForce cards from working in passthrough, but because it is not officially supported for GeForce cards, this will not be fixed.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

mbroemme

Member

From: Cologne

Registered: 2014-02-05

Posts: 40

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

Urks...

daxcore

Member

Registered: 2014-05-19

Posts: 1

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

I think I found ultimate fix for code 43 on windows and RmInitAdapter failed on linux with nvidia devices with newer driver.
What I did was masking hypervisor cpuid signature and voala!!!

Apparently the driver checking for hypervisor cpuid signature and bail if detecting presence of those signature unless the gpu is nvidia GRID.
After 2 frustrating weeks at last.
F*ck you nvidia!!!

Wow, I was suspicious, but didn't actually think nvidia would sink this low to try it.  I suppose there's still a chance that it was an oversight and not an attempt to be malicious.  Maybe we can make a runtime option for qemu to hide the hypervisor.

It's also sufficient to just change the signature, for instance:

--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -528,7 +528,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
         has_msr_hv_hypercall = true;
     }
 
-    memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+    memcpy(signature, "kvmkvmkvm\0\0\0", 12);
     c = &cpuid_data.entries[cpuid_i++];
     c->function = KVM_CPUID_SIGNATURE | kvm_base;
     c->eax = 0;

Thanks, working great!

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Alex, so anymore ideas to my lcpsi output at post #1849 and #1850?

None yet.  I was going to suggest that we should save/restore ATS support as part of bus reset path since that's the only notable difference in #1849, but then I found that we already do that, so I don't know why it's showing up disabled.  For #1850, does a host suspend/resume make it work or is that just another failing case?  The differences in the correctable error status registers don't seem like they should make a difference.

mbroemme, ok, here's an idea.  I think your non-working R9 290X reports NoSoftRst-, right?  IOW, it does claim to support a PM reset.  Maybe we shouldn't be trusting that PM reset is not horribly broken on this device.  We can make a device specific reset that will supersede and invalidate the standard reset mechanisms, leaving us with only bus reset.  Let's try something like this:

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e729206..946f8d8 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3295,6 +3295,12 @@ static int reset_chelsio_generic_dev(struct pci_dev *dev,
        return 0;
 }
 
+static int reset_no_reset(struct pci_dev *dev, int probe)
+{
+       printk("%s(%s, %d)\n", __func__, dev_name(&dev->dev), probe);
+       return -EINVAL;
+}
+
 #define PCI_DEVICE_ID_INTEL_82599_SFP_VF   0x10ed
 #define PCI_DEVICE_ID_INTEL_IVB_M_VGA      0x0156
 #define PCI_DEVICE_ID_INTEL_IVB_M2_VGA     0x0166
@@ -3310,6 +3316,8 @@ static const struct pci_dev_reset_methods pci_dev_reset_me
                reset_intel_generic_dev },
        { PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
                reset_chelsio_generic_dev },
+       { PCI_VENDOR_ID_AMD, $GPU_DEVICE_ID, reset_no_reset },
+       { PCI_VENDOR_ID_AMD, $AUDIO_DEVICE_ID, reset_no_reset },
        { 0 }
 };
 

Replace the $GPU_DEVICE_ID and $AUDIO_DEVICE_ID with the ones for your R9 290X in standard hex notation.  Let us know what happens.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

mbroemme

Member

From: Cologne

Registered: 2014-02-05

Posts: 40

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

Alex, so anymore ideas to my lcpsi output at post #1849 and #1850?

None yet.  I was going to suggest that we should save/restore ATS support as part of bus reset path since that's the only notable difference in #1849, but then I found that we already do that, so I don't know why it's showing up disabled.  For #1850, does a host suspend/resume make it work or is that just another failing case?  The differences in the correctable error status registers don't seem like they should make a difference.

mbroemme, ok, here's an idea.  I think your non-working R9 290X reports NoSoftRst-, right?  IOW, it does claim to support a PM reset.  Maybe we shouldn't be trusting that PM reset is not horribly broken on this device.  We can make a device specific reset that will supersede and invalidate the standard reset mechanisms, leaving us with only bus reset.  Let's try something like this:

Unfortunately no.

	Capabilities: [50] 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-

sonnet

Member

Registered: 2014-01-30

Posts: 3

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

I have one monitor with only a single dvi-d connection (no vga, no hdmi, no second dvi-d).
I have 2 vga though (integrated hd 4600 which i intended to use as main vga, and a radeon r9 270 to use for the vm)
Also my cpu and motherboard both support vt-d extension.

Can I take advantage of vga-passthrough for my vm, without attaching the second vga (R9 270) to the monitor? (since having only one connection I have no other choice).

I'm asking because I saw this video:
[YOUTUBE]Qi1LdFkRzIs[/YOUTUBE]

You can see the guy is running the vm in windowed mode, with vga passthrough enabled. Being the vm in windowed mode (rather than controlling the whole monitor)
makes me think like only is main vga (the vga that is used by the host) is controlling and attached to the monitor.

Can please anyone clarify?

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

I have one monitor with only a single dvi-d connection (no vga, no hdmi, no second dvi-d).
I have 2 vga though (integrated hd 4600 which i intended to use as main vga, and a radeon r9 270 to use for the vm)
Also my cpu and motherboard both support vt-d extension.

Can I take advantage of vga-passthrough for my vm, without attaching the second vga (R9 270) to the monitor? (since having only one connection I have no other choice).

I'm asking because I saw this video:
[YOUTUBE]Qi1LdFkRzIs[/YOUTUBE]

You can see the guy is running the vm in windowed mode, with vga passthrough enabled. Being the vm in windowed mode (rather than controlling the whole monitor)
makes me think like only is main vga (the vga that is used by the host) is controlling and attached to the monitor.

Can please anyone clarify?

The video is using a VNC server running inside the guest and a VNC client on the desktop.  You have all the same remote graphics tricks at your disposal with VGA assignment as you do with physically separate systems.

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

None yet.  I was going to suggest that we should save/restore ATS support as part of bus reset path since that's the only notable difference in #1849, but then I found that we already do that, so I don't know why it's showing up disabled.  For #1850, does a host suspend/resume make it work or is that just another failing case?  The differences in the correctable error status registers don't seem like they should make a difference.

mbroemme, ok, here's an idea.  I think your non-working R9 290X reports NoSoftRst-, right?  IOW, it does claim to support a PM reset.  Maybe we shouldn't be trusting that PM reset is not horribly broken on this device.  We can make a device specific reset that will supersede and invalidate the standard reset mechanisms, leaving us with only bus reset.  Let's try something like this:

Unfortunately no.

	Capabilities: [50] 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-

/me goes back to beating head against desk

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

mbroemme

Member

From: Cologne

Registered: 2014-02-05

Posts: 40

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

/me goes back to beating head against desk

aw, this card is a "real" beast. All my other AMD cards are working fine (HD 7870 GHz, HD 5450 and HD 6670), but as time comes we might find a solution which will be helpful for other cards too I believe.

Last edited by mbroemme (2014-06-03 22:01:51)

sonnet

Member

Registered: 2014-01-30

Posts: 3

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

The video is using a VNC server running inside the guest and a VNC client on the desktop.  You have all the same remote graphics tricks at your disposal with VGA assignment as you do with physically separate systems.

Thanks for your reply.
So do I need to have both the vga connected to the monitors or this escamotage with VNC would allow me to not connect the guest os card to the monitor?
Because my monitor allows only one connection (so there's no way I can attach 2 vga to the monitor)

Last edited by sonnet (2014-06-03 17:38:58)

apex8

Member

Registered: 2014-03-29

Posts: 60

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

@sonnet
You only need the physical monitor connection to the vm for the vnc server setup in the vm. Once this is done you can connect to the vnc desktop from your host using a vnc client.

aw

Member

Registered: 2013-10-04

Posts: 921

Website

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

Or you can setup everything with emulated VGA and switch over to the assigned VGA only after you have VNC access

---

http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses?  Try https://www.redhat.com/mailman/listinfo/vfio-users

sonnet

Member

Registered: 2014-01-30

Posts: 3

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

Thanks guys for your advices!
Does anybody have an idea about the overhead (in partiular % of cpu resources, considering I have a quadcore haswell) caused by this method with vnc?

Last edited by sonnet (2014-06-03 20:36:09)