KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9 (Page 108) / Kernel & Hardware / Arch Linux Forums

You are not logged in.

Topics: Active | Unanswered

Pages: Previous 1 … 106 107 108 109 110 … 234 Next

Topic closed

#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

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

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. 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: 20,203

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

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

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
...
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
...
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

Pages: Previous 1 … 106 107 108 109 110 … 234 Next

Topic closed

Board footer

Atom topic feed

Arch Linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Board footer