You are not logged in.

#2676 2014-09-08 00:57:52

risho
Member
Registered: 2011-09-06
Posts: 44

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

okay i've been messing with it more and i'm still getting the same problems

test.sh

#qemu-system-x86_64 -enable-kvm  -m 1024 -cpu host \
#-smp 6,sockets=1,cores=2,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 -enable-kvm -M q35 -m 4096 -cpu host,kvm=off \
        -smp 2,sockets=1,cores=2,threads=1 \
        -bios /usr/share/qemu/bios.bin -vga none\
        -rtc base=localtime \
        -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 \

sh test.sh

qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error opening /dev/vfio/15: Permission denied
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 15
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

sudo sh test.sh

No protocol specified
Could not initialize SDL(No available video device) - exiting

sh lsgroup

....
### Group 15 ###
    01:00.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 580] (rev a1)
    01:00.1 Audio device: NVIDIA Corporation GF110 High Definition Audio Controller (rev a1)
....



### Group 0 ###
    00:00.0 Host bridge: Intel Corporation 4th Gen Core 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)
### Group 2 ###
    00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core 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 9 Series Chipset Family USB xHCI Controller
### Group 5 ###
    00:16.0 Communication controller: Intel Corporation 9 Series Chipset Family ME Interface #1
### Group 6 ###
    00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V
### Group 7 ###
    00:1a.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2
### Group 8 ###
    00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
### Group 9 ###
    00:1c.0 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 (rev d0)
### Group 10 ###
    00:1c.2 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 3 (rev d0)
### Group 11 ###
    00:1c.3 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 4 (rev d0)
### Group 12 ###
    00:1c.6 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 7 (rev d0)
### Group 13 ###
    00:1d.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1
### Group 14 ###
    00:1f.0 ISA bridge: Intel Corporation 9 Series Chipset Family Z97 LPC Controller
    00:1f.2 SATA controller: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode]
    00:1f.3 SMBus: Intel Corporation 9 Series Chipset Family SMBus Controller



### Group 16 ###
    03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
### Group 17 ###
    04:00.0 PCI bridge: ASMedia Technology Inc. Device 1184
### Group 18 ###
    05:01.0 PCI bridge: ASMedia Technology Inc. Device 1184
### Group 19 ###
    05:03.0 PCI bridge: ASMedia Technology Inc. Device 1184
### Group 20 ###
    05:05.0 PCI bridge: ASMedia Technology Inc. Device 1184
### Group 21 ###
    05:07.0 PCI bridge: ASMedia Technology Inc. Device 1184
### Group 22 ###
    06:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
### Group 23 ###
    07:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)
### Group 24 ###
    08:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
### Group 25 ###
    09:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)
### Group 26 ###
    0a:00.0 USB controller: ASMedia Technology Inc. Device 1142

lspci -nn

....
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF110 [GeForce GTX 580] [10de:1080] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GF110 High Definition Audio Controller [10de:0e09] (rev a1)
....

00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06)
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:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06)
00:14.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB xHCI Controller [8086:8cb1]
00:16.0 Communication controller [0780]: Intel Corporation 9 Series Chipset Family ME Interface #1 [8086:8cba]
00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) I218-V [8086:15a1]
00:1a.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2 [8086:8cad]
00:1b.0 Audio device [0403]: Intel Corporation 9 Series Chipset Family HD Audio Controller [8086:8ca0]
00:1c.0 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 [8086:8c90] (rev d0)
00:1c.2 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 3 [8086:8c94] (rev d0)
00:1c.3 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 4 [8086:8c96] (rev d0)
00:1c.6 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 7 [8086:8c9c] (rev d0)
00:1d.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1 [8086:8ca6]
00:1f.0 ISA bridge [0601]: Intel Corporation 9 Series Chipset Family Z97 LPC Controller [8086:8cc4]
00:1f.2 SATA controller [0106]: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode] [8086:8c82]
00:1f.3 SMBus [0c05]: Intel Corporation 9 Series Chipset Family SMBus Controller [8086:8ca2]
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 11)
04:00.0 PCI bridge [0604]: ASMedia Technology Inc. Device [1b21:1184]
05:01.0 PCI bridge [0604]: ASMedia Technology Inc. Device [1b21:1184]
05:03.0 PCI bridge [0604]: ASMedia Technology Inc. Device [1b21:1184]
05:05.0 PCI bridge [0604]: ASMedia Technology Inc. Device [1b21:1184]
05:07.0 PCI bridge [0604]: ASMedia Technology Inc. Device [1b21:1184]
06:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller [1912:0014] (rev 03)
07:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02)
08:00.0 Network controller [0280]: Qualcomm Atheros AR93xx Wireless Network Adapter [168c:0030] (rev 01)
09:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02)
0a:00.0 USB controller [0c03]: ASMedia Technology Inc. Device [1b21:1142]

sh vfio-group 15

0000:01:00.0
0000:01:00.1
0x10de 0x1080

boot parameters

LABEL arch-qemu
   MENU LABEL Arch Qemu
   LINUX ../vmlinuz-linux-mainline
   APPEND root=/dev/sdb1 rootflags=subvol=__active/rootvol intel_iommu=on i915.enable_hd_vgaarb=1 pcie_acs_override=downstream pci-stub.ids=10de:1080,10de:0e09,8086:0c01 modeset.nouveau=0 modeset.radeon=0 rw
   INITRD ../initramfs-linux-mainline.img

i use vfiobind

sudo vfio-bind 0000:01:00.0 0000:01:00.1

dmesg | grep -e DMAR -e IOMMU

[    0.000000] Warning: PCIe ACS overrides enabled; This may allow non-IOMMU protected peer-to-peer DMA
[    0.000000] ACPI: DMAR 0x00000000BD1C3BC8 0000B8 (v01 INTEL  BDW      00000001 INTL 00000001)
[    0.000000] Intel-IOMMU: enabled
[    0.026976] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020660462 ecap f0101a
[    0.026979] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap d2008c20660462 ecap f010da
[    0.027044] IOAPIC id 8 under DRHD base  0xfed91000 IOMMU 1
[    0.523584] DMAR: No ATSR found
[    0.523601] IOMMU 0 0xfed90000: using Queued invalidation
[    0.523601] IOMMU 1 0xfed91000: using Queued invalidation
[    0.523603] IOMMU: Setting RMRR:
[    0.523610] IOMMU: Setting identity map for device 0000:00:02.0 [0xbf000000 - 0xcf1fffff]
[    0.524672] IOMMU: Setting identity map for device 0000:00:14.0 [0xbde9a000 - 0xbdea8fff]
[    0.524691] IOMMU: Setting identity map for device 0000:00:1a.0 [0xbde9a000 - 0xbdea8fff]
[    0.524707] IOMMU: Setting identity map for device 0000:00:1d.0 [0xbde9a000 - 0xbdea8fff]
[    0.524718] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    0.524724] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[    2.613731] [drm] DMAR active, disabling use of stolen memory

i am absolutely lost and do not know what i can do next

by the way tuxuser thank you very much for pointing out those scripts to me they are really helpful.

does anyone have any ideas?

Last edited by risho (2014-09-08 01:02:36)

Offline

#2677 2014-09-08 01:33:50

tuxuser
Member
Registered: 2014-08-23
Posts: 8

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

@risho I haven't dealt with that vfio permission problem myself.   Does dmesg and lspci -v indicate that pci-stub claimed the device?  I assume your pci-stub support is built into the kernel.

EDIT:  as far as the SDL problem, i assume you are launching from Xorg, but just pass -nographic for now

for my case support is as a module and I wrote about this earlier

[root@archost ~]# zgrep PCI_STUB /proc/config.gz 
CONFIG_PCI_STUB=m

[root@archost ~]# dmesg|grep stub
[    0.456853] pci-stub: add 10DE:1183 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    0.456860] pci-stub 0000:01:00.0: claimed by stub
[    0.456863] pci-stub: add 10DE:0E0A sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    0.456867] pci-stub 0000:01:00.1: claimed by stub
[    0.456868] pci-stub: add 8086:1E20 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[    0.456871] pci-stub 0000:00:1b.0: claimed by stub

Last edited by tuxuser (2014-09-08 01:48:46)

Offline

#2678 2014-09-08 01:51:46

risho
Member
Registered: 2011-09-06
Posts: 44

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

lspci-v

...
01:00.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 580] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: eVga.com. Corp. Device 1580
        Flags: fast devsel, IRQ 16
        Memory at ee000000 (32-bit, non-prefetchable) [size=16M]
        Memory at e0000000 (64-bit, prefetchable) [size=128M]
        Memory at e8000000 (64-bit, prefetchable) [size=32M]
        I/O ports at e000 [size=128]
        Expansion ROM at ef000000 [disabled] [size=512K]
        Capabilities: <access denied>
        Kernel driver in use: vfio-pci
        Kernel modules: nouveau

01:00.1 Audio device: NVIDIA Corporation GF110 High Definition Audio Controller (rev a1)
        Subsystem: eVga.com. Corp. Device 1580
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at ef080000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: vfio-pci
        Kernel modules: snd_hda_intel
...

00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
        Subsystem: ASRock Incorporation Device 0c00
        Flags: bus master, fast devsel, latency 0
        Capabilities: <access denied>
        Kernel driver in use: hsw_uncore

00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000e000-0000efff
        Memory behind bridge: ee000000-ef0fffff
        Prefetchable memory behind bridge: 00000000e0000000-00000000e9ffffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
        Subsystem: ASRock Incorporation Device 0412
        Flags: bus master, fast devsel, latency 0, IRQ 72
        Memory at ef400000 (64-bit, non-prefetchable) [size=4M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at f000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: <access denied>
        Kernel driver in use: i915
        Kernel modules: i915

00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
        Subsystem: ASRock Incorporation Device 0c0c
        Flags: bus master, fast devsel, latency 0, IRQ 73
        Memory at efe34000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB xHCI Controller (prog-if 30 [XHCI])
        Subsystem: ASRock Incorporation Device 8cb1
        Flags: bus master, medium devsel, latency 0, IRQ 48
        Memory at efe20000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_hcd

00:16.0 Communication controller: Intel Corporation 9 Series Chipset Family ME Interface #1
        Subsystem: ASRock Incorporation Device 8cba
        Flags: bus master, fast devsel, latency 0, IRQ 68
        Memory at efe3e000 (64-bit, non-prefetchable) [size=16]
        Capabilities: <access denied>
        Kernel driver in use: mei_me
        Kernel modules: mei_me

00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V
        Subsystem: ASRock Incorporation Device 15a1
        Flags: bus master, fast devsel, latency 0, IRQ 69
        Memory at efe00000 (32-bit, non-prefetchable) [size=128K]
        Memory at efe3c000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at f080 [size=32]
        Capabilities: <access denied>
        Kernel driver in use: e1000e
        Kernel modules: e1000e

00:1a.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2 (prog-if 20 [EHCI])
        Subsystem: ASRock Incorporation Device 8cad
        Flags: bus master, medium devsel, latency 0, IRQ 16
        Memory at efe3b000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: <access denied>
        Kernel driver in use: ehci-pci
        Kernel modules: ehci_pci

00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
        Subsystem: ASRock Incorporation Device 1151
        Flags: bus master, fast devsel, latency 0, IRQ 71
        Memory at efe30000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 (rev d0) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

00:1c.2 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 3 (rev d0) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: efd00000-efdfffff
        Prefetchable memory behind bridge: 00000000ea100000-00000000ea1fffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

00:1c.3 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 4 (rev d0) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=04, subordinate=09, sec-latency=0
        I/O behind bridge: 0000b000-0000cfff
        Memory behind bridge: ef800000-efbfffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

00:1c.6 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 7 (rev d0) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
        Memory behind bridge: efc00000-efcfffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

00:1d.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1 (prog-if 20 [EHCI])
        Subsystem: ASRock Incorporation Device 8ca6
        Flags: bus master, medium devsel, latency 0, IRQ 23
        Memory at efe3a000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: <access denied>
        Kernel driver in use: ehci-pci
        Kernel modules: ehci_pci

00:1f.0 ISA bridge: Intel Corporation 9 Series Chipset Family Z97 LPC Controller
        Subsystem: ASRock Incorporation Device 8cc4
        Flags: bus master, medium devsel, latency 0
        Capabilities: <access denied>

00:1f.2 SATA controller: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode] (prog-if 01 [AHCI 1.0])
        Subsystem: ASRock Incorporation Device 8c82
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 49
        I/O ports at f0d0 [size=8]
        I/O ports at f0c0 [size=4]
        I/O ports at f0b0 [size=8]
        I/O ports at f0a0 [size=4]
        I/O ports at f060 [size=32]
        Memory at efe39000 (32-bit, non-prefetchable) [size=2K]
        Capabilities: <access denied>
        Kernel driver in use: ahci
        Kernel modules: ahci

00:1f.3 SMBus: Intel Corporation 9 Series Chipset Family SMBus Controller
        Subsystem: ASRock Incorporation Device 8ca2
        Flags: medium devsel, IRQ 10
        Memory at efe38000 (64-bit, non-prefetchable) [size=256]
        I/O ports at f040 [size=32]











03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
        Subsystem: ASRock Incorporation Motherboard (one of many)
        Flags: bus master, fast devsel, latency 0, IRQ 70
        I/O ports at d000 [size=256]
        Memory at efd00000 (64-bit, non-prefetchable) [size=4K]
        Memory at ea100000 (64-bit, prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8169

04:00.0 PCI bridge: ASMedia Technology Inc. Device 1184 (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=04, secondary=05, subordinate=09, sec-latency=0
        I/O behind bridge: 0000b000-0000cfff
        Memory behind bridge: ef800000-efbfffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

05:01.0 PCI bridge: ASMedia Technology Inc. Device 1184 (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=05, secondary=06, subordinate=06, sec-latency=0
        Memory behind bridge: efb00000-efbfffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

05:03.0 PCI bridge: ASMedia Technology Inc. Device 1184 (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=05, secondary=07, subordinate=07, sec-latency=0
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: efa00000-efafffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

05:05.0 PCI bridge: ASMedia Technology Inc. Device 1184 (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=05, secondary=08, subordinate=08, sec-latency=0
        Memory behind bridge: ef900000-ef9fffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

05:07.0 PCI bridge: ASMedia Technology Inc. Device 1184 (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=05, secondary=09, subordinate=09, sec-latency=0
        I/O behind bridge: 0000b000-0000bfff
        Memory behind bridge: ef800000-ef8fffff
        Capabilities: <access denied>
        Kernel driver in use: pcieport
        Kernel modules: shpchp

06:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI])
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at efb00000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: <access denied>
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_hcd

07:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) (prog-if 01 [AHCI 1.0])
        Subsystem: ASRock Incorporation Motherboard
        Flags: bus master, fast devsel, latency 0, IRQ 58
        I/O ports at c050 [size=8]
        I/O ports at c040 [size=4]
        I/O ports at c030 [size=8]
        I/O ports at c020 [size=4]
        I/O ports at c000 [size=32]
        Memory at efa00000 (32-bit, non-prefetchable) [size=512]
        Capabilities: <access denied>
        Kernel driver in use: ahci
        Kernel modules: ahci

08:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
        Subsystem: Qualcomm Atheros Device 3112
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at ef900000 (64-bit, non-prefetchable) [size=128K]
        Expansion ROM at ef920000 [disabled] [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: ath9k
        Kernel modules: ath9k

09:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) (prog-if 01 [AHCI 1.0])
        Subsystem: ASRock Incorporation Motherboard
        Flags: bus master, fast devsel, latency 0, IRQ 59
        I/O ports at b050 [size=8]
        I/O ports at b040 [size=4]
        I/O ports at b030 [size=8]
        I/O ports at b020 [size=4]
        I/O ports at b000 [size=32]
        Memory at ef800000 (32-bit, non-prefetchable) [size=512]
        Capabilities: <access denied>
        Kernel driver in use: ahci
        Kernel modules: ahci

0a:00.0 USB controller: ASMedia Technology Inc. Device 1142 (prog-if 30 [XHCI])
        Subsystem: ASRock Incorporation Device 1142
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at efc00000 (64-bit, non-prefetchable) [size=32K]
        Capabilities: <access denied>
        Kernel driver in use: xhci_hcd
        Kernel modules: xhci_hcd

dmesg | grep vfio-pci

[  304.062334] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003) 

interesting the card says

01:00.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 580] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: eVga.com. Corp. Device 1580
        Flags: fast devsel, IRQ 16
        Memory at ee000000 (32-bit, non-prefetchable) [size=16M]
        Memory at e0000000 (64-bit, prefetchable) [size=128M]
        Memory at e8000000 (64-bit, prefetchable) [size=32M]
        I/O ports at e000 [size=128]
        Expansion ROM at ef000000 [disabled] [size=512K]
        Capabilities: <access denied>
        Kernel driver in use: vfio-pci
        Kernel modules: nouveau
i dunno if that means it isnt being blacklisted?


EDIT:

EDIT:  as far as the SDL problem, i assume you are launching from Xorg, but just pass -nographic for now

yes i am running from inside xorg


i changed test.sh to:

#qemu-system-x86_64 -enable-kvm  -m 1024 -cpu host \
#-smp 6,sockets=1,cores=2,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 -enable-kvm -M q35 -m 4096 -cpu host,kvm=off \
        -smp 2,sockets=1,cores=2,threads=1 \
        -bios /usr/share/qemu/bios.bin -vga none\
        -rtc base=localtime \
        -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 -nographic \###altered line to add -nographic
        -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 \

it grabs the terminal and gives no output which makes me assume its working. in order to get the terminal back i have to kill qemu-x86_64(or whatever it was extactly). then when i ran it again

i got

qemu-system-x86_64: vfio-pci: Cannot read device rom at 0000:01:00.0                                                                                                                                                                                                           
Device option ROM contents are probably invalid (check dmesg).                                                                                                                                                                                                                 
Skip option ROM probe with rombar=0, or load from file with romfile=     

Last edited by risho (2014-09-08 01:59:20)

Offline

#2679 2014-09-08 01:57:37

aw
Member
Registered: 2013-10-04
Posts: 921
Website

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

risho, if you don't run as root then you need to change the permissions of the files for the user to access them and set the locked memory limit for the user to match that necessary for the guest.  Just run as root and use the -nographic option so that QEMU won't try to create an SDL window.


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

Offline

#2680 2014-09-08 02:05:17

risho
Member
Registered: 2011-09-06
Posts: 44

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

i got it working. you guys are amazing. thank you so much for the help.

now i have a couple more questions. i killed qemu and the monitor is still being shown as if the vm were still running. (it's not even holding the terminal window anymore) how do i correctly shutdown the vm from inside the host?

Last edited by risho (2014-09-08 02:06:28)

Offline

#2681 2014-09-08 02:08:12

tuxuser
Member
Registered: 2014-08-23
Posts: 8

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

instead of kill the term, if you hit CTRL A C you can get a qemu monitor prompt and just type quit,   in the log run this is why you want to either setup qemu monitor for telnet access or use gnu screen or some people go libvirt.

EDIT:  during testing i will do the following:
stop
system_reset
quit


This cleans up the passthough screen nicely.   And that's nice to hear aw's update about 3.17 smile

Last edited by tuxuser (2014-09-08 02:13:17)

Offline

#2682 2014-09-08 02:10:11

aw
Member
Registered: 2013-10-04
Posts: 921
Website

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

risho wrote:

i got it working. you guys are amazing. thank you so much for the help.

now i have a couple more questions. i killed qemu and the monitor is still being shown as if the vm were still running. (it's not even holding the terminal window anymore) how do i correctly shutdown the vm from inside the host?

Since you're trying to assign nvidia, this should be fixed in 3.17.  A bus reset will be done when the devices are released if any of the devices require it and all of the affected devices are bound to vfio-pci.  (It will also work for radeon cards that report NoSoftRst+)


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

Offline

#2683 2014-09-09 13:56:43

noobman
Member
Registered: 2013-12-13
Posts: 21

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

I have an old idea that i think it is worth a thought. The normal bug/feedback reporting path is tedious and i think most ppls just wait and let somebody else do it. Speaking plainly, how about a site like kerneltest.org, where willing users can/could upload the output of some script or could enable a kernel cli of a module auto reporting tool (or something that is automatic and standardised enough). Sort of something non invasive and only user volontary. Like a sort of automatic reporting tool, not for developers, but for what is actually happening in the wild. I dont mind giving that kind of info as long as its entirely optional/volontary, code is transparent and whats being sent is visible and approvable. I think it would be a lot of good information offered by this process, not to mention nice statistics like how many bugs affect how many machines and of which type. Can be applied different ways, overall or in part. Like if some users want to test some "vfio" branch and have a script report back the issues of that branch exactly. Or if on their turn, are dubious about some other pull request, can ask the guy on that branch to first show say 100 unique reports that patch boots ok on 100 different machines. But something like this needs some form of "official" backing otherwise wont get traction. And has to rely on automatic reporting coz of user lazyness, and also to have a standardisation for data processing. I am generally stumped as how redhat has an automatic bug reporting tool (of sorts) and something much more global like kernel.org does not have a similar straightforward feedback shortcut. Well, not my place to comment, but really its just a thought.
Or maybe if you want to provide a script of some sorts, me and maybe a couple of other ppls on the thread would be happy to volonteer running it for you to get whatever info you may wish to have. And that would be in a fairly standardized manner. Meaning the data can be processed further, statistical and so on. In comparison i think most of the comments on the thread are just like any other thread, basic impressions and contextual ones, not quite able to be processed furtner because of not having details like configs, context, versions, etc. Hence quite limited usability and prone to the normal distribution being applied to ppls abilities - to put things in a nice way.

Offline

#2684 2014-09-09 14:16:17

noobman
Member
Registered: 2013-12-13
Posts: 21

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

system_reset

system_reset  -- reset the system || as if you hit the reset button while machine is running;
system_powerdown  -- send system power down event || as if it would be turned off from inside start menu; if you have sound, you will hear the windows sutdown sound, so this is normal shutdown. Also with this you should not need stop and quit, if the machine closes normally the qemu terminal will close too by itself.
in qemu terminal, type 'help' for a list of commands, or 'info' for getting detailed machine information

Last edited by noobman (2014-09-09 14:21:30)

Offline

#2685 2014-09-09 15:32:54

sinny
Member
Registered: 2014-05-24
Posts: 75

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

noobman wrote:

...
I am generally stumped as how redhat has an automatic bug reporting tool (of sorts) and something much more global like kernel.org does not have a similar straightforward feedback shortcut.
...

well, "redhat" is a distro, while "kernel.org" is distro-agnostic software piece (a core one for all the distros out there). "automatic bug reporting tool" assumes some degree of usage of distro's infrastructure. still feeling stumped?

p.s. your idea was too vague for me to grasp from the text you wrote (purpose? subject?), but judging by what i think i understood from your posts, this is too little gains for huge trouble to make it work (if possible at all, considering all the distro/setup variety out there)

Offline

#2686 2014-09-09 16:07:37

tuxuser
Member
Registered: 2014-08-23
Posts: 8

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

noobman wrote:

system_reset

system_reset  -- reset the system || as if you hit the reset button while machine is running;
system_powerdown  -- send system power down event || as if it would be turned off from inside start menu; if you have sound, you will hear the windows sutdown sound, so this is normal shutdown. Also with this you should not need stop and quit, if the machine closes normally the qemu terminal will close too by itself.
in qemu terminal, type 'help' for a list of commands, or 'info' for getting detailed machine information


noobman the context that system_reset was suggested was "testing" which you may not have a booted OS (ie no drives attached and just testing pt output).  system_powerdown does not nothing for me at the Seabios screen or inside a installer with no shutdown option.  Of course under normal circumstances you want want to do a graceful shutdown.  I thought this was self explanitory...

Offline

#2687 2014-09-09 17:57:33

noobman
Member
Registered: 2013-12-13
Posts: 21

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

sinny wrote:
noobman wrote:

...
I am generally stumped as how redhat has an automatic bug reporting tool (of sorts) and something much more global like kernel.org does not have a similar straightforward feedback shortcut.
...

well, "redhat" is a distro, while "kernel.org" is distro-agnostic software piece (a core one for all the distros out there). "automatic bug reporting tool" assumes some degree of usage of distro's infrastructure. still feeling stumped?

p.s. your idea was too vague for me to grasp from the text you wrote (purpose? subject?), but judging by what i think i understood from your posts, this is too little gains for huge trouble to make it work (if possible at all, considering all the distro/setup variety out there)

Yes well, as i said, its not for me to comment, just an ideea. Regarding its implementation, i dont think its impossible, nothing really is. This very thread goes towards doing something that once was not possible. And most likely just like anything else, could be implemented in a variety of ways, not just one. Then the usual, many choices to be made in that regard, etc. About distro related, could be something like only distro having src or pkg for each distro, or being half module half distro script, or maybe just rely on a kernel module alone, dunno. However i certainly think its not "impossible". These days is hard to find a thing that really is. Harder or easier yes, but impossible - dunno. So the distro part i can see that, but i think its far from being an insurmontable obstacle.

What i said its just an ideea, having shortest and most standardized feedback possible for what is being done. This is the abstract idea alone. Its not even IT specific, but like information systems, more used in other places/industries which rely on feedback and where quality is a direct function of feedback and how its being implemented. And if in general the quality depends on the feedback, so is the case with kernel: where would kernel be with no bug reports ever. And hence one step further, the better feedback (more accurate, more standardised) should go towards applying same attributes to the release product. Better feedback, better product. Otherwise feedback does not just improve the main process, but nowadays its integral part of many things as a process. As it being universal, for example you can not have a stepper motor without feedback - it just can function without it, feedback is integrated in functioning principle because it needs a closed loop to start with, the entire thing relies on that. Many may consider it differently but the feedback like it is now, bug reports that take 2 weeks + 20 comments before somebody posts an actual gdb trace is something i would (as a matter of personal opinion), i would qualify that lacking, no standardisation, bad or poor quality feedback with as little context info as possible. Then i dunno how something so big and complex as the kernel cand work with that feedback of little drips of info (where it should be a river of information). So yes im still stumped, from the perspective i am looking. Thumbs up for the army of ppls, including volonteers, digging in all that and sorting the issues one by one, from where i am looking that is really nothing short of a miracle.

So again, ofc it is just an abstract sort of more or less universal idea, widely applicable. The "how to do it" its hierarhically different question. No point going further into it, because its not my place. I just do think that could make a good difference in many situations. Like imagine you look at all the gathered data from 10k machines for xx-test-rc3, and you see 80% having an issue, one could figure out its a regression of some kind from previous, easier and faster to pinpoint. And you dont have to wait 3 months before somebody puts a bug notification and then bisects everything back to rc3 from rc2 to find the culprit. Or we can imagine other scenarios where one branch change is not being credible but it can become so when its backed by xyz reports of running ok. Or the other way around, discard a patch coz of bad reports. We can play with the scenarios like these as long as we want, maybe some can imagine a scenario where it would hurt, but i think in general it would be a good thing, ofc depends on how its implemented and used. Again, as an abstraction any tool cuts both ways, but when it cuts the user, its user fault. No point playing the "what-if" game.

The context, or the place of this is, i would like to help, i could give feedback, but i am a poor user, very limited in knowledge, and ofc very lazy. In other words typical. So realistically things must not rely on my iq or work ability, else will certainly fail. smile Hence it needs to be automated and standardised. I dont think there is a single company with marketing division providing a feedback that relies on its clients inteligence or their work addiction - or if there is one, i would not buy that stock. So about bad SNR signal to noise ratio - true that, but it can be changed and improved. Not at the user base level (again coz normal repartition is a bitch when applied to human qualities), but it can be changed at the process level.

Sry cant elaborate further, as i said its just an idea, and pretty abstract one for that matter, tho quite widely applied. Ppls may like or dislike the ideea, again, its just an opinion, mine, im entitled to one, so here it is/was thrown in. All my concerns rest, further idc, so ill rest. Ofc ppls may think differently, and by all means they better should. Thats the good part, and its how things get filtered.

Offline

#2688 2014-09-09 19:42:44

noobman
Member
Registered: 2013-12-13
Posts: 21

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

tuxuser wrote:

noobman the context that system_reset was suggested was "testing" which you may not have a booted OS (ie no drives attached and just testing pt output).  system_powerdown does not nothing for me at the Seabios screen or inside a installer with no shutdown option.  Of course under normal circumstances you want want to do a graceful shutdown.  I thought this was self explanitory...

Yes sry then my bad, i assumed it was an os running inside the machine. Otherwise i (personally) dont care how i shut down the vm. If i have an os running, only then i care because i have open files, could loose data, etc, and then if i just close the process then windows will have dirty bit set and next time will scandisk at boot time. Else with no software in machine i would not care how i close it (but that might be just my personal choice). Anyway i didnt thought of that case really, i just assumed the machine has an os.

Offline

#2689 2014-09-09 23:06:18

abdullah
Member
Registered: 2014-06-10
Posts: 34

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

It would be nice to see a X99 motherboard do this as a multi-headed PC.

And I want to show off my work, but I want to show a Linux Distro (host), VM1(Windows) and VM2(MAC OS), the problem is, where do I get MAC OS !? it seems they only come with apple MACs.

Offline

#2690 2014-09-10 00:58:54

zsph
Member
Registered: 2014-09-04
Posts: 9

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

I have a problem with suspend/resume my host. I searched the whole thread and this topic was brought up a few times but I couldn't get any hints. After using qemu and successfully shutting down the Windows guest I can no longer send the host to sleep. My desktop remains visible and frozen.

Afterwards I tried to run qemu without disks to only show seabieos, hoping it would release or reset the vfio devices. That way I can suspend but when resuming back there is no signal from iGPU, even REISUB doesn't help. Only hard reset.

I also tried to unbind the devices from vfio-pci and bind to drivers_probe but it didn't work out.


Asus P8Z77-V LK, Core i7 3770, Asus NVIDIA GTX 770 DirectCU II OC, Debian x64, EFI, Kernel 3.16 + i915 arbiter patch.
3DMark11: bare metal P10231 vs vfio P10039: 98% of performance!

Offline

#2691 2014-09-10 01:33:11

mauorrizze
Member
Registered: 2014-08-22
Posts: 18

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

abdullah wrote:

[...] the problem is, where do I get MAC OS !? it seems they only come with apple MACs.

Apple forbids the installation of OSX on non-Apple-hardware and there even don't exist installation discs any more. <Moderator edit.  Redacted>

It might be allowed to run a virtualized OSX with Linux KVM on Apple hardware. But if one would try something like this, it might be best to use a graphics card that is natively supported in OS X -> hardware database
KVM infos:
http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ (page 28 in this thread)
http://www.reddit.com/r/hackintosh/comm … _with_vga/

Last edited by ewaller (2014-09-10 02:26:38)

Offline

#2692 2014-09-10 02:24:41

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,739

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

As a moderator, I am obliged to step in here and insist there be no further discussion that encourages or provides information as to violate copyright restrictions. 
Our policy with regards to the facilitation of copyright violation

Thank you.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#2693 2014-09-10 05:48:43

friedcpu
Member
Registered: 2014-09-03
Posts: 3

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

Has anyone tried running any EA Origin Games in their Windows VM?

I am running Windows 7 x64 Enterprise and trying to run The Sims 4 (for the mrs, got to keep her happy) and it just refuses to open, I can see in task manager it opens the process, and then it just dies, can't find anything in any log files in Windows telling me whats going on and nothing happens on screen. If I boot the hard drive natively it works fine (installed windows through qemu and all drivers, I just swap the gfx card back to slot 1 and boot natively to test). My qemu settings are

qemu-system-x86_64 -enable-kvm -M q35 -m 16384 -cpu host,kvm=off \
-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=03:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=03:00.1,bus=root.1,addr=00.1 \
-device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \
-device virtio-scsi-pci,id=scsi \
-drive file=/dev/sde,id=boot,format=raw -device scsi-hd,drive=boot \
-drive file=/dev/sdf,id=storage,format=raw -device scsi-hd,drive=storage \
-usb -usbdevice host:046d:c07d -usbdevice host:of39:1084 \
-nographic -boot menu=on

System specs are:
ASUS x79-deluxe Motherboard
Intel 4930k CPU
64GB RAM
3x250GB Samsung EVO SSD (1 host, 1 for each VM)
2x3TB WD RED (1 for each VM)
1x2TB Seagate (for host, other VMs with no GPU passthrough)
AMD HD5450 (Host)
NVIDIA GTX550Ti (Yet Unknown VM)
NVIDIA GTX770 (Windows VM)

I have also tried with passing through the sata controller (which works on first boot, but if I reboot the VM it causes seabios to hang, can't figure it out its an ASM1602 Which is known to be a problem in passthrough) but still no difference. There isn't really any performance gain from using native sata than the scsi controller.

Any help would be greatly appreciated, otherwise I'm going to have to keep a separate Windows install just for her to boot natively thus shutting down all my VM's sad

Last edited by friedcpu (2014-09-10 05:49:20)

Offline

#2694 2014-09-10 15:26:05

aw
Member
Registered: 2013-10-04
Posts: 921
Website

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

friedcpu wrote:

Has anyone tried running any EA Origin Games in their Windows VM?

Isn't BF4 an EA Origin game?  We seem to have reports of that working.  I try to avoid EA on principle.

Have you tried the ignore_msrs=1 option for the kvm module?

Did you re-install the game as well as the OS?  Perhaps some of the DRM that EA is so well known for doesn't like the change in computer platform.


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

Offline

#2695 2014-09-10 19:09:30

Cubex
Member
Registered: 2014-04-06
Posts: 24

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

I will post this little Python script that I made which grabs device ids from linux commandline and returns the corresponding PCI bus ids, useful to pass returning list to vfio-bind script:

#!/usr/bin/env python
"""This script grabs pci bus from vendor:device using pci stubs from linux cmdline"""

from subprocess import Popen, PIPE

PCISTUB_CMD = "pci-stub.ids="

def shell(cmd, args = ""):
    """Runs shell command"""
    proc = Popen([cmd, args], stdout = PIPE, stderr = PIPE)
    result, error = proc.communicate()
    if error:
        raise Exception(error)
    return result

def get_linux_pcistub():
    """Returns dev ids list"""
    linux_cmds = shell("cat", "/proc/cmdline")
    for cmd in linux_cmds.split(" "):
        if PCISTUB_CMD in cmd:
            return cmd.split("=")[1]

pcidevs = ""
devids = get_linux_pcistub()
if devids is not None:
    for devid in devids.split(","):
        if devid: #devid is valid
            pcdidevid = shell("lspci", "-d " + devid)
            if pcdidevid: #we found existing pci bus
                pcidevs += " 0000:" + pcdidevid[:7]

print(pcidevs)

Last edited by Cubex (2014-09-10 19:22:12)

Offline

#2696 2014-09-11 10:19:10

guildem
Member
Registered: 2014-09-11
Posts: 4

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

I all, I have some trouble when I try to do a vga passthrough with my system.

First thing, sorry for my bad english, i'm french, and you know what they say about french people and foreign languages smile

So this is my config :

CM: Asrock Z97 Extreme 6
Proc: i7 4790k
Ram: 16GB
Host GPU: HD Graphics 4600
Guest GPU: Radeon HD 5850

Some informations :

- I use only repo packages, with last updates, no AUR, no patches
- kernel 3.16.2-1, qemu 2.1.0-2

My lspci dump :

02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cypress PRO [Radeon HD 5850] [1002:6899] (prog-if 00 [VGA controller])
02:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cypress HDMI Audio [Radeon HD 5800 Series] [1002:aa50]

On my syslinux boot i added :

intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 pci-stub.ids=1002:6899,1002:aa50

I've added this script :

vfio-bind 0000:02:00.0 0000:02:00.1

And this is my qemu command :

qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host \
    -smp 4,sockets=1,cores=4,threads=1 \
    -usbdevice tablet -usbdevice host:046d:c52e \
    -bios /usr/share/qemu/bios.bin -vga cirrus \
    -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 \
    -device piix4-ide,bus=pcie.0,id=piix4-ide \
    -drive file=seven.img,id=disk,format=qcow2 -device ide-hd,bus=piix4-ide.0,drive=disk \
    -drive file=software/iso/windows-seven-x64.iso,id=isocd -device ide-cd,bus=piix4-ide.1,drive=isocd \
    -soundhw hda

And now the weird thing : you'll notice the "-vga cirrus" option. when I put this option on cirrus, I boot on a cirrus card, and view my Seven desktop (all installed). If I try to view my graphic cards on the guest, I see 2 cards, the "cirrus" one acting as a VGA standard graphic card, and a second one "AMD Radeon HD 5800 Series" (i installed AMD's Catalyst driver), with an error : "this device can't find enough free resources to work correctly" (translated from French).

If I put a "-vga none" option on my qemu, I see only the compat_monitor console and nothing shown on my AMD VGA screen. And I have the color glitch on my iGPU screen (I go on tty mode and go back on X to remove it).

I don't know what else I can do to have something on my AMD screen...

Thanks for your help !

Guildem

Offline

#2697 2014-09-11 10:23:45

dwe11er
Member
Registered: 2014-03-18
Posts: 73

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

guildem wrote:

I all, I have some trouble when I try to do a vga passthrough with my system.

First thing, sorry for my bad english, i'm french, and you know what they say about french people and foreign languages smile

...

If I put a "-vga none" option on my qemu, I see only the compat_monitor console and nothing shown on my AMD VGA screen. And I have the color glitch on my iGPU screen (I go on tty mode and go back on X to remove it).

I don't know what else I can do to have something on my AMD screen...

Thanks for your help !

Guildem

Have you even read first post?

Anyway, you need to patch your kernel with i915 vgaarb patch.

Offline

#2698 2014-09-11 12:07:43

guildem
Member
Registered: 2014-09-11
Posts: 4

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

dwe11er wrote:
guildem wrote:

I all, I have some trouble when I try to do a vga passthrough with my system.

First thing, sorry for my bad english, i'm french, and you know what they say about french people and foreign languages smile

...

If I put a "-vga none" option on my qemu, I see only the compat_monitor console and nothing shown on my AMD VGA screen. And I have the color glitch on my iGPU screen (I go on tty mode and go back on X to remove it).

I don't know what else I can do to have something on my AMD screen...

Thanks for your help !

Guildem

Have you even read first post?

Anyway, you need to patch your kernel with i915 vgaarb patch.

HI dwe11er,

Thank you for your answer. Yes, I saw the first post, and other articles too. I didn't view all the pages but I tried to find some informations.

I am not an expert and I try to learn all those things, but posts I found talk about many distribs, many kernels, many case (intel or amd cpu, amd or nvidia gpu,...). So this is difficult  to find a good answer for my configuration.

I didn't used patches because I found people saying that they didn't patch their kernel. With your answer, I think that those people have an amd cpu.
I saw this i915 vgaarb patch may be in the 3.17 RC3 kernel. Is it true? I'll try to find informations about this patch. And I'll may compile the patched kernel of the first post to try it... or wait for 3.17...

I was thinking if I see the graphic card on the guest, all was OK with my stock kernel.

Thanks again!

Guildem

Offline

#2699 2014-09-11 13:05:17

aw
Member
Registered: 2013-10-04
Posts: 921
Website

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

guildem wrote:

I saw this i915 vgaarb patch may be in the 3.17 RC3 kernel. Is it true?

No, the other VGA arbiter patch is in 3.17, the i915 patch is not currently scheduled for any upstream kernel and is a blocking issue for using an unmodified kernel for users with IGD.  Those reporting success with an unmodified kernel probably don't have IGD or are not following the directions and using their GPU as a secondary card for the VM.  Please see the articles at the URL below, especially the FAQ for more info.


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

Offline

#2700 2014-09-11 13:20:53

guildem
Member
Registered: 2014-09-11
Posts: 4

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

aw wrote:
guildem wrote:

I saw this i915 vgaarb patch may be in the 3.17 RC3 kernel. Is it true?

No, the other VGA arbiter patch is in 3.17, the i915 patch is not currently scheduled for any upstream kernel and is a blocking issue for using an unmodified kernel for users with IGD.  Those reporting success with an unmodified kernel probably don't have IGD or are not following the directions and using their GPU as a secondary card for the VM.  Please see the articles at the URL below, especially the FAQ for more info.

Thanks aw, that is not a good news... i'll read the posts on your link too.

Offline

Board footer

Powered by FluxBB