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

dwe11er · 2014-08-04 15:42:49

rg80 wrote:

rg80 wrote:
Hi again.
Do you have any idea how to add -cpu kvm=off option into a virt-manager xml?
I already tried with qemu arg:
    <qemu:arg value='-cpu'/>
    <qemu:arg value='kvm=off'/>
but it does not work.
Should i put it somewhere into CPU options?
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='4' threads='2'/>
  </cpu>
Thanks.
Bumping in a different format.
I want to disable the KVM Signture to update my nvidia windows drivers to any newer than v335.
Then got latest GIT version of qemu, applied this patch, then config, make, make install, reboot.
Applied:
    <qemu:arg value='-cpu'/>
    <qemu:arg value='host,kvm=off'/>
but qemu reports .kvm is not an available option for qemu-system-x86_64.
On the contrary:
    <qemu:arg value='-cpu'/>
    <qemu:arg value='host,hv-time'/>
works.
Am i doing something wrong?
Note:
For some reason, the original patch posted on page 1 gives me a format error on:
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
it's not a blank, i can't understand where the problem is...
Thanks!

I belive qemu from git has this patch already applied.

rg80 · 2014-08-04 15:46:41

I belive qemu from git has this patch already applied.

Thanks, I believe the same but what is the -cpu option then?
I also tried without patch but it does not work on its own and -cpu kvm=off gives the same error with libvirt.

rg80 · 2014-08-04 19:17:49

Got it!

virsh XML was pointing to /user/bin/qemu while git qemu installs into /usr/local/bin/qemu !!!

Changed the path in the XML, added:

    <qemu:arg value='-cpu'/>
    <qemu:arg value='host,kvm=off'/>

Now i am on nvidia with windows driver 340!

And yes, qemu git already contains the "-cpu kvm" option, no need to apply any patch!

HPvirt · 2014-08-04 22:27:39

Hello!

Previously, I've checked if some hardware would be able to do this kind of virtualization.
Now, I have my hardware (check my signature for details).

I started yesterday to prepare my linux for virt. (kernel compilation, grub command line,...). I've tried with kernel 3.15.6 with the 3 patches from #1. Without success: no /etc/vfio/x, qemu would not start.

And tonight, I've succeeded to start Seven SP1 boot CD! I used kernel 3.15.8 sources, apply patches, build, install, and it works.
First step done.

I've tried to read all posts. Sorting all these infos (obsolete one, AMD specific, etc.) to apply them to my specific case is quite time consuming, but it's very usefull. However, as I'm more linux user than administrator, I think I've missed some part, and there's some things I do not understand fully.

So, before going into the real seven installation, I've some questions:
- I do not use pci-stub: as I understand the first post, it must be used only if we cannot blacklist GPU drivers (as with 2 NVidia or 2 AMD). Right?
- I want to install Seven on a SSD, so I would like to have AHCI and trim working for Windows. Between solutions on #1 for giving access to disk drives, which one is recommanded?
- Moving windows under Linux is... smooth... too smooth, producing great latency: my cursor is already stopped and the window is still moving to overtake the cursor. Is the disabling of DRI the cause? If I boot from liveCD, I have the same behavior.
- In first post, I do not understand the part "Systemd service:". I think I must add a file containing following text to do the vfio bindings at start time. But I would like to be sure... Can someone confirm please?

Some info:

$ grep VFIO /boot/config-3.15.8
CONFIG_VFIO_IOMMU_TYPE1=y
CONFIG_VFIO=y
CONFIG_VFIO_PCI=y
CONFIG_VFIO_PCI_VGA=y
CONFIG_KVM_VFIO=y

$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-3.15.8 root=UUID=a98c98e2-53a6-4771-a465-e5dd7128ae4e ro quiet splash nvidia.blacklist=yes nvidia-current.blacklist=yes nvidia_337.blacklist=yes nvidiafb.blacklist=yes i915.enable_hd_vgaarb=1 intel_iommu=on vt.handoff=7

For the cmdline, I followed post #2308 as rafalcieslak have the same hardware.

I do not use (cf. #2308):

options kvm allow_unsafe_assigned_interrupts=1

nor (not yet):

pcie_acs_override=downstream

About this last parameter, is it a requisite? I've check groups, and if I fully give ASMedia USB & Sata controllers and Realtek Network controller to Seven, as they share the same group, it would not be necessary. Or, more likely, I missed something...

(lsgroup is aw script in #722)

$ ./lsgroup.sh 
### 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)
    01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1)
    01:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1)
### 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 Device 8cb1
### Group 5 ###
    00:16.0 Communication controller: Intel Corporation Device 8cba
### Group 6 ###
    00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V
### Group 7 ###
    00:1a.0 USB controller: Intel Corporation Device 8cad
### Group 8 ###
    00:1b.0 Audio device: Intel Corporation Device 8ca0
### Group 9 ###
    00:1c.0 PCI bridge: Intel Corporation Device 8c90 (rev d0)
    00:1c.2 PCI bridge: Intel Corporation Device 8c94 (rev d0)
    00:1c.3 PCI bridge: Intel Corporation Device 8c96 (rev d0)
    00:1c.6 PCI bridge: Intel Corporation Device 8c9c (rev d0)
    03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
    04:00.0 PCI bridge: ASMedia Technology Inc. Device 1184
    05:01.0 PCI bridge: ASMedia Technology Inc. Device 1184
    05:03.0 PCI bridge: ASMedia Technology Inc. Device 1184
    05:05.0 PCI bridge: ASMedia Technology Inc. Device 1184
    05:07.0 PCI bridge: ASMedia Technology Inc. Device 1184
    07:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)
    09:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)
    0a:00.0 USB controller: ASMedia Technology Inc. Device 1142
### Group 10 ###
    00:1d.0 USB controller: Intel Corporation Device 8ca6
### Group 11 ###
    00:1f.0 ISA bridge: Intel Corporation Device 8cc4
    00:1f.2 SATA controller: Intel Corporation Device 8c82
    00:1f.3 SMBus: Intel Corporation Device 8ca2

Thank you all for sharing your knowledge.
I hope I'm understandable as my english is not pretty good...

Last edited by HPvirt (2014-08-06 20:36:00)

slis · 2014-08-05 05:38:52

you must use pci-stub if u have 2 same cards, for host and guest.

maybe you need option downstream if u have 2 gpu-s (maybe even if u don't, depending on mbo)...

you need to bind device before u start vm, with systemd service or by hand (vfio-bind 0000:01:00.0 0000:01:00.1, assumin u created vfio-bind script as in first post)

not sure about window lag, i don't use gui on host.

about ssd... i am not sure, but i think u need to pass whole sata controller to use trim etc...

virtio-disk is best option if u ask me

edit:
check my posts for configs and help...

Last edited by slis (2014-08-05 05:54:17)

monchi · 2014-08-05 06:29:29

are the patches from #1 still needed for the recent stabel kernel version 3.16 ?

zerotri · 2014-08-05 08:01:54

I seem to have made a bit of progress on a few fronts but still have a ways to go.

I ended up not using pci-stub at all. This may or may not be causing problems. lspci -v shows that my first hd6770 is bound to radeon while my second is bound to vfio-pci. Host's graphics are working 100% but when I start up a windows guest I am getting the infamous "video_tdr_failure / atikmpag.sys" BSoD. I've tried playing around with moving the HDMI audio device to a few other pci locations, as well as not passing it through at all, with no luck. Maybe I'm doing something wrong in the process of debugging that.

Also, I was able to turn off the DMAR error associated with my Marvell controller by completely disabling the device in my bios. Now my system boots up pretty quickly, just need to iron out the vga passthrough issues with the vm.

I guess this could be contributing to the issue?
Gonna have to dig around in dmesg a bit more to see if I'm missing anything else.

[    4.894003] VFIO - User Level meta-driver version: 0.3
[    4.897769] scsi 8:0:0:0: Direct-Access     SanDisk  Cruzer Fit       1.22 PQ: 0 ANSI: 5
[    4.898516] sd 8:0:0:0: [sdc] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
[    4.899512] sd 8:0:0:0: [sdc] Write Protect is off
[    4.899515] sd 8:0:0:0: [sdc] Mode Sense: 43 00 00 00
[    4.899873] sd 8:0:0:0: Attached scsi generic sg2 type 0
[    4.900960] sd 8:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    4.908768] ------------[ cut here ]------------
[    4.908774] WARNING: CPU: 5 PID: 956 at fs/sysfs/group.c:219 sysfs_remove_group+0x93/0xa0()
[    4.908776] sysfs group ffffffff81cb8dc0 not found for kobject 'i2c-21'
[    4.908777] Modules linked in: vfio_iommu_type1 vfio_pci vfio joydev uas usb_storage hid_logitech_dj iTCO_wdt iTCO_vendor_support eeepc_wmi asus_wmi sparse_keymap video mxm_wmi vfat fat x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_codec_hdmi serio_raw btusb sb_edac edac_core bluetooth snd_hda_intel snd_hda_controller snd_hda_codec i2c_i801 rfkill snd_hwdep snd_seq snd_seq_device lpc_ich mfd_core snd_pcm snd_timer mei_me snd mei soundcore shpchp wmi nfsd auth_rpcgss nfs_acl lockd sunrpc radeon i2c_algo_bit drm_kms_helper e1000e ttm drm ptp i2c_core pps_core
[    4.908811] CPU: 5 PID: 956 Comm: vfio-bind Not tainted 3.15.7-200.fc20.x86_64 #1
[    4.908813] Hardware name: System manufacturer System Product Name/P9X79 PRO, BIOS 1203 05/24/2012
[    4.908814]  0000000000000000 000000002e9d5df5 ffff8808078abba0 ffffffff816ef92e
[    4.908816]  ffff8808078abbe8 ffff8808078abbd8 ffffffff8108933d 0000000000000000
[    4.908818]  ffffffff81cb8dc0 ffff88080eef2480 ffff88080fedb000 ffff88080eef24c8
[    4.908821] Call Trace:
[    4.908825]  [<ffffffff816ef92e>] dump_stack+0x45/0x56
[    4.908827]  [<ffffffff8108933d>] warn_slowpath_common+0x7d/0xa0
[    4.908829]  [<ffffffff810893bc>] warn_slowpath_fmt+0x5c/0x80
[    4.908832]  [<ffffffff81260918>] ? kernfs_find_and_get_ns+0x48/0x60
[    4.908834]  [<ffffffff81263fc3>] sysfs_remove_group+0x93/0xa0
[    4.908837]  [<ffffffff81465197>] dpm_sysfs_remove+0x57/0x60
[    4.908840]  [<ffffffff8145a1f5>] device_del+0x45/0x1c0
[    4.908841]  [<ffffffff8145a38e>] device_unregister+0x1e/0x60
[    4.908848]  [<ffffffffa000cd2c>] i2c_del_adapter+0x1bc/0x2f0 [i2c_core]
[    4.908852]  [<ffffffffa0093412>] drm_dp_aux_unregister_i2c_bus+0x12/0x20 [drm_kms_helper]
[    4.908867]  [<ffffffffa01812fc>] radeon_i2c_destroy+0x3c/0x40 [radeon]
[    4.908878]  [<ffffffffa018137a>] radeon_i2c_fini+0x2a/0x50 [radeon]
[    4.908890]  [<ffffffffa017e6d9>] radeon_modeset_fini+0x89/0x90 [radeon]
[    4.908899]  [<ffffffffa0157180>] radeon_driver_unload_kms+0x40/0x60 [radeon]
[    4.908908]  [<ffffffffa00497a9>] drm_dev_unregister+0x29/0xb0 [drm]
[    4.908915]  [<ffffffffa0049d13>] drm_put_dev+0x23/0x70 [drm]
[    4.908923]  [<ffffffffa015327d>] radeon_pci_remove+0x1d/0x20 [radeon]
[    4.908927]  [<ffffffff8138fb7b>] pci_device_remove+0x3b/0xb0
[    4.908930]  [<ffffffff8145e48f>] __device_release_driver+0x7f/0xf0
[    4.908932]  [<ffffffff8145e523>] device_release_driver+0x23/0x30
[    4.908935]  [<ffffffff8145d06d>] unbind_store+0xbd/0xe0
[    4.908937]  [<ffffffff8145c574>] drv_attr_store+0x24/0x40
[    4.908939]  [<ffffffff81262c1d>] sysfs_kf_write+0x3d/0x50
[    4.908941]  [<ffffffff812623e0>] kernfs_fop_write+0xe0/0x160
[    4.908944]  [<ffffffff811e67da>] vfs_write+0xba/0x1e0
[    4.908946]  [<ffffffff811e7395>] SyS_write+0x55/0xd0
[    4.908950]  [<ffffffff816ff969>] system_call_fastpath+0x16/0x1b
[    4.908951] ---[ end trace 4a930f0eb6428dc9 ]---
[    4.908985] ------------[ cut here ]------------
[    4.908988] WARNING: CPU: 5 PID: 956 at fs/sysfs/group.c:219 sysfs_remove_group+0x93/0xa0()
[    4.908989] sysfs group ffffffff81cb8dc0 not found for kobject 'i2c-24'
[    4.908989] Modules linked in: vfio_iommu_type1 vfio_pci vfio joydev uas usb_storage hid_logitech_dj iTCO_wdt iTCO_vendor_support eeepc_wmi asus_wmi sparse_keymap video mxm_wmi vfat fat x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_codec_hdmi serio_raw btusb sb_edac edac_core bluetooth snd_hda_intel snd_hda_controller snd_hda_codec i2c_i801 rfkill snd_hwdep snd_seq snd_seq_device lpc_ich mfd_core snd_pcm snd_timer mei_me snd mei soundcore shpchp wmi nfsd auth_rpcgss nfs_acl lockd sunrpc radeon i2c_algo_bit drm_kms_helper e1000e ttm drm ptp i2c_core pps_core
[    4.909015] CPU: 5 PID: 956 Comm: vfio-bind Tainted: G        W     3.15.7-200.fc20.x86_64 #1
[    4.909016] Hardware name: System manufacturer System Product Name/P9X79 PRO, BIOS 1203 05/24/2012
[    4.909017]  0000000000000000 000000002e9d5df5 ffff8808078abba0 ffffffff816ef92e
[    4.909019]  ffff8808078abbe8 ffff8808078abbd8 ffffffff8108933d 0000000000000000
[    4.909021]  ffffffff81cb8dc0 ffff88080eef2c80 ffff88080fedf000 ffff88080eef2cc8
[    4.909023] Call Trace:
[    4.909025]  [<ffffffff816ef92e>] dump_stack+0x45/0x56
[    4.909027]  [<ffffffff8108933d>] warn_slowpath_common+0x7d/0xa0
[    4.909029]  [<ffffffff810893bc>] warn_slowpath_fmt+0x5c/0x80
[    4.909031]  [<ffffffff81260918>] ? kernfs_find_and_get_ns+0x48/0x60
[    4.909033]  [<ffffffff81263fc3>] sysfs_remove_group+0x93/0xa0
[    4.909035]  [<ffffffff81465197>] dpm_sysfs_remove+0x57/0x60
[    4.909037]  [<ffffffff8145a1f5>] device_del+0x45/0x1c0
[    4.909039]  [<ffffffff8145a38e>] device_unregister+0x1e/0x60
[    4.909044]  [<ffffffffa000cd2c>] i2c_del_adapter+0x1bc/0x2f0 [i2c_core]
[    4.909048]  [<ffffffffa0093412>] drm_dp_aux_unregister_i2c_bus+0x12/0x20 [drm_kms_helper]
[    4.909060]  [<ffffffffa01812fc>] radeon_i2c_destroy+0x3c/0x40 [radeon]
[    4.909071]  [<ffffffffa018137a>] radeon_i2c_fini+0x2a/0x50 [radeon]
[    4.909082]  [<ffffffffa017e6d9>] radeon_modeset_fini+0x89/0x90 [radeon]
[    4.909091]  [<ffffffffa0157180>] radeon_driver_unload_kms+0x40/0x60 [radeon]
[    4.909098]  [<ffffffffa00497a9>] drm_dev_unregister+0x29/0xb0 [drm]
[    4.909105]  [<ffffffffa0049d13>] drm_put_dev+0x23/0x70 [drm]
[    4.909114]  [<ffffffffa015327d>] radeon_pci_remove+0x1d/0x20 [radeon]
[    4.909116]  [<ffffffff8138fb7b>] pci_device_remove+0x3b/0xb0
[    4.909119]  [<ffffffff8145e48f>] __device_release_driver+0x7f/0xf0
[    4.909122]  [<ffffffff8145e523>] device_release_driver+0x23/0x30
[    4.909124]  [<ffffffff8145d06d>] unbind_store+0xbd/0xe0
[    4.909126]  [<ffffffff8145c574>] drv_attr_store+0x24/0x40
[    4.909128]  [<ffffffff81262c1d>] sysfs_kf_write+0x3d/0x50
[    4.909130]  [<ffffffff812623e0>] kernfs_fop_write+0xe0/0x160
[    4.909133]  [<ffffffff811e67da>] vfs_write+0xba/0x1e0
[    4.909135]  [<ffffffff811e7395>] SyS_write+0x55/0xd0
[    4.909137]  [<ffffffff816ff969>] system_call_fastpath+0x16/0x1b
[    4.909139] ---[ end trace 4a930f0eb6428dca ]---
[    4.909163] ------------[ cut here ]------------
[    4.909166] WARNING: CPU: 5 PID: 956 at fs/sysfs/group.c:219 sysfs_remove_group+0x93/0xa0()
[    4.909167] sysfs group ffffffff81cb8dc0 not found for kobject 'i2c-22'
[    4.909168] Modules linked in: vfio_iommu_type1 vfio_pci vfio joydev uas usb_storage hid_logitech_dj iTCO_wdt iTCO_vendor_support eeepc_wmi asus_wmi sparse_keymap video mxm_wmi vfat fat x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_codec_hdmi serio_raw btusb sb_edac edac_core bluetooth snd_hda_intel snd_hda_controller snd_hda_codec i2c_i801 rfkill snd_hwdep snd_seq snd_seq_device lpc_ich mfd_core snd_pcm snd_timer mei_me snd mei soundcore shpchp wmi nfsd auth_rpcgss nfs_acl lockd sunrpc radeon i2c_algo_bit drm_kms_helper e1000e ttm drm ptp i2c_core pps_core
[    4.909193] CPU: 5 PID: 956 Comm: vfio-bind Tainted: G        W     3.15.7-200.fc20.x86_64 #1
[    4.909195] Hardware name: System manufacturer System Product Name/P9X79 PRO, BIOS 1203 05/24/2012
[    4.909195]  0000000000000000 000000002e9d5df5 ffff8808078abba0 ffffffff816ef92e
[    4.909197]  ffff8808078abbe8 ffff8808078abbd8 ffffffff8108933d 0000000000000000
[    4.909200]  ffffffff81cb8dc0 ffff88080eef3480 ffff88080fedc000 ffff88080eef34c8
[    4.909202] Call Trace:
[    4.909204]  [<ffffffff816ef92e>] dump_stack+0x45/0x56
[    4.909206]  [<ffffffff8108933d>] warn_slowpath_common+0x7d/0xa0
[    4.909208]  [<ffffffff810893bc>] warn_slowpath_fmt+0x5c/0x80
[    4.909210]  [<ffffffff81260918>] ? kernfs_find_and_get_ns+0x48/0x60
[    4.909212]  [<ffffffff81263fc3>] sysfs_remove_group+0x93/0xa0
[    4.909214]  [<ffffffff81465197>] dpm_sysfs_remove+0x57/0x60
[    4.909216]  [<ffffffff8145a1f5>] device_del+0x45/0x1c0
[    4.909218]  [<ffffffff8145a38e>] device_unregister+0x1e/0x60
[    4.909223]  [<ffffffffa000cd2c>] i2c_del_adapter+0x1bc/0x2f0 [i2c_core]
[    4.909228]  [<ffffffffa0093412>] drm_dp_aux_unregister_i2c_bus+0x12/0x20 [drm_kms_helper]
[    4.909241]  [<ffffffffa01812fc>] radeon_i2c_destroy+0x3c/0x40 [radeon]
[    4.909253]  [<ffffffffa018137a>] radeon_i2c_fini+0x2a/0x50 [radeon]
[    4.909264]  [<ffffffffa017e6d9>] radeon_modeset_fini+0x89/0x90 [radeon]
[    4.909273]  [<ffffffffa0157180>] radeon_driver_unload_kms+0x40/0x60 [radeon]
[    4.909281]  [<ffffffffa00497a9>] drm_dev_unregister+0x29/0xb0 [drm]
[    4.909288]  [<ffffffffa0049d13>] drm_put_dev+0x23/0x70 [drm]
[    4.909296]  [<ffffffffa015327d>] radeon_pci_remove+0x1d/0x20 [radeon]
[    4.909299]  [<ffffffff8138fb7b>] pci_device_remove+0x3b/0xb0
[    4.909303]  [<ffffffff8145e48f>] __device_release_driver+0x7f/0xf0
[    4.909305]  [<ffffffff8145e523>] device_release_driver+0x23/0x30
[    4.909307]  [<ffffffff8145d06d>] unbind_store+0xbd/0xe0
[    4.909309]  [<ffffffff8145c574>] drv_attr_store+0x24/0x40
[    4.909312]  [<ffffffff81262c1d>] sysfs_kf_write+0x3d/0x50
[    4.909314]  [<ffffffff812623e0>] kernfs_fop_write+0xe0/0x160
[    4.909316]  [<ffffffff811e67da>] vfs_write+0xba/0x1e0
[    4.909318]  [<ffffffff811e7395>] SyS_write+0x55/0xd0
[    4.909321]  [<ffffffff816ff969>] system_call_fastpath+0x16/0x1b
[    4.909323] ---[ end trace 4a930f0eb6428dcb ]---
[    4.909353] ------------[ cut here ]------------
[    4.909356] WARNING: CPU: 5 PID: 956 at fs/sysfs/group.c:219 sysfs_remove_group+0x93/0xa0()
[    4.909357] sysfs group ffffffff81cb8dc0 not found for kobject 'i2c-23'
[    4.909358] Modules linked in: vfio_iommu_type1 vfio_pci vfio joydev uas usb_storage hid_logitech_dj iTCO_wdt iTCO_vendor_support eeepc_wmi asus_wmi sparse_keymap video mxm_wmi vfat fat x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_codec_hdmi serio_raw btusb sb_edac edac_core bluetooth snd_hda_intel snd_hda_controller snd_hda_codec i2c_i801 rfkill snd_hwdep snd_seq snd_seq_device lpc_ich mfd_core snd_pcm snd_timer mei_me snd mei soundcore shpchp wmi nfsd auth_rpcgss nfs_acl lockd sunrpc radeon i2c_algo_bit drm_kms_helper e1000e ttm drm ptp i2c_core pps_core
[    4.909385] CPU: 5 PID: 956 Comm: vfio-bind Tainted: G        W     3.15.7-200.fc20.x86_64 #1
[    4.909386] Hardware name: System manufacturer System Product Name/P9X79 PRO, BIOS 1203 05/24/2012
[    4.909387]  0000000000000000 000000002e9d5df5 ffff8808078abba0 ffffffff816ef92e
[    4.909389]  ffff8808078abbe8 ffff8808078abbd8 ffffffff8108933d 0000000000000000
[    4.909391]  ffffffff81cb8dc0 ffff88080eef3c80 ffff88080fede800 ffff88080eef3cc8
[    4.909394] Call Trace:
[    4.909396]  [<ffffffff816ef92e>] dump_stack+0x45/0x56
[    4.909398]  [<ffffffff8108933d>] warn_slowpath_common+0x7d/0xa0
[    4.909400]  [<ffffffff810893bc>] warn_slowpath_fmt+0x5c/0x80
[    4.909403]  [<ffffffff816f526b>] ? mutex_unlock+0x1b/0x20
[    4.909406]  [<ffffffff81260918>] ? kernfs_find_and_get_ns+0x48/0x60
[    4.909408]  [<ffffffff81263fc3>] sysfs_remove_group+0x93/0xa0
[    4.909410]  [<ffffffff81465197>] dpm_sysfs_remove+0x57/0x60
[    4.909412]  [<ffffffff8145a1f5>] device_del+0x45/0x1c0
[    4.909414]  [<ffffffff8145a38e>] device_unregister+0x1e/0x60
[    4.909419]  [<ffffffffa000cd2c>] i2c_del_adapter+0x1bc/0x2f0 [i2c_core]
[    4.909423]  [<ffffffffa0093412>] drm_dp_aux_unregister_i2c_bus+0x12/0x20 [drm_kms_helper]
[    4.909435]  [<ffffffffa01812fc>] radeon_i2c_destroy+0x3c/0x40 [radeon]
[    4.909446]  [<ffffffffa018137a>] radeon_i2c_fini+0x2a/0x50 [radeon]
[    4.909457]  [<ffffffffa017e6d9>] radeon_modeset_fini+0x89/0x90 [radeon]
[    4.909466]  [<ffffffffa0157180>] radeon_driver_unload_kms+0x40/0x60 [radeon]
[    4.909479]  [<ffffffffa00497a9>] drm_dev_unregister+0x29/0xb0 [drm]
[    4.909486]  [<ffffffffa0049d13>] drm_put_dev+0x23/0x70 [drm]
[    4.909494]  [<ffffffffa015327d>] radeon_pci_remove+0x1d/0x20 [radeon]
[    4.909497]  [<ffffffff8138fb7b>] pci_device_remove+0x3b/0xb0
[    4.909500]  [<ffffffff8145e48f>] __device_release_driver+0x7f/0xf0
[    4.909502]  [<ffffffff8145e523>] device_release_driver+0x23/0x30
[    4.909504]  [<ffffffff8145d06d>] unbind_store+0xbd/0xe0
[    4.909506]  [<ffffffff8145c574>] drv_attr_store+0x24/0x40
[    4.909509]  [<ffffffff81262c1d>] sysfs_kf_write+0x3d/0x50
[    4.909511]  [<ffffffff812623e0>] kernfs_fop_write+0xe0/0x160
[    4.909513]  [<ffffffff811e67da>] vfs_write+0xba/0x1e0
[    4.909515]  [<ffffffff811e7395>] SyS_write+0x55/0xd0
[    4.909517]  [<ffffffff816ff969>] system_call_fastpath+0x16/0x1b
[    4.909519] ---[ end trace 4a930f0eb6428dcc ]---
[    4.909550] ------------[ cut here ]------------
[    4.909552] WARNING: CPU: 5 PID: 956 at fs/sysfs/group.c:219 sysfs_remove_group+0x93/0xa0()
[    4.909554] sysfs group ffffffff81cb8dc0 not found for kobject 'i2c-25'
[    4.909554] Modules linked in: vfio_iommu_type1 vfio_pci vfio joydev uas usb_storage hid_logitech_dj iTCO_wdt iTCO_vendor_support eeepc_wmi asus_wmi sparse_keymap video mxm_wmi vfat fat x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_codec_hdmi serio_raw btusb sb_edac edac_core bluetooth snd_hda_intel snd_hda_controller snd_hda_codec i2c_i801 rfkill snd_hwdep snd_seq snd_seq_device lpc_ich mfd_core snd_pcm snd_timer mei_me snd mei soundcore shpchp wmi nfsd auth_rpcgss nfs_acl lockd sunrpc radeon i2c_algo_bit drm_kms_helper e1000e ttm drm ptp i2c_core pps_core
[    4.909580] CPU: 5 PID: 956 Comm: vfio-bind Tainted: G        W     3.15.7-200.fc20.x86_64 #1
[    4.909581] Hardware name: System manufacturer System Product Name/P9X79 PRO, BIOS 1203 05/24/2012
[    4.909582]  0000000000000000 000000002e9d5df5 ffff8808078abba0 ffffffff816ef92e
[    4.909584]  ffff8808078abbe8 ffff8808078abbd8 ffffffff8108933d 0000000000000000
[    4.909585]  ffffffff81cb8dc0 ffff88080eef4480 ffff88080fedf400 ffff88080eef44c8
[    4.909587] Call Trace:
[    4.909590]  [<ffffffff816ef92e>] dump_stack+0x45/0x56
[    4.909591]  [<ffffffff8108933d>] warn_slowpath_common+0x7d/0xa0
[    4.909593]  [<ffffffff810893bc>] warn_slowpath_fmt+0x5c/0x80
[    4.909595]  [<ffffffff81260918>] ? kernfs_find_and_get_ns+0x48/0x60
[    4.909597]  [<ffffffff81263fc3>] sysfs_remove_group+0x93/0xa0
[    4.909599]  [<ffffffff81465197>] dpm_sysfs_remove+0x57/0x60
[    4.909601]  [<ffffffff8145a1f5>] device_del+0x45/0x1c0
[    4.909603]  [<ffffffff8145a38e>] device_unregister+0x1e/0x60
[    4.909608]  [<ffffffffa000cd2c>] i2c_del_adapter+0x1bc/0x2f0 [i2c_core]
[    4.909612]  [<ffffffffa0093412>] drm_dp_aux_unregister_i2c_bus+0x12/0x20 [drm_kms_helper]
[    4.909623]  [<ffffffffa01812fc>] radeon_i2c_destroy+0x3c/0x40 [radeon]
[    4.909634]  [<ffffffffa018137a>] radeon_i2c_fini+0x2a/0x50 [radeon]
[    4.909645]  [<ffffffffa017e6d9>] radeon_modeset_fini+0x89/0x90 [radeon]
[    4.909654]  [<ffffffffa0157180>] radeon_driver_unload_kms+0x40/0x60 [radeon]
[    4.909661]  [<ffffffffa00497a9>] drm_dev_unregister+0x29/0xb0 [drm]
[    4.909667]  [<ffffffffa0049d13>] drm_put_dev+0x23/0x70 [drm]
[    4.909675]  [<ffffffffa015327d>] radeon_pci_remove+0x1d/0x20 [radeon]
[    4.909678]  [<ffffffff8138fb7b>] pci_device_remove+0x3b/0xb0
[    4.909681]  [<ffffffff8145e48f>] __device_release_driver+0x7f/0xf0
[    4.909683]  [<ffffffff8145e523>] device_release_driver+0x23/0x30
[    4.909685]  [<ffffffff8145d06d>] unbind_store+0xbd/0xe0
[    4.909687]  [<ffffffff8145c574>] drv_attr_store+0x24/0x40
[    4.909689]  [<ffffffff81262c1d>] sysfs_kf_write+0x3d/0x50
[    4.909691]  [<ffffffff812623e0>] kernfs_fop_write+0xe0/0x160
[    4.909693]  [<ffffffff811e67da>] vfs_write+0xba/0x1e0
[    4.909696]  [<ffffffff811e7395>] SyS_write+0x55/0xd0
[    4.909698]  [<ffffffff816ff969>] system_call_fastpath+0x16/0x1b
[    4.909700] ---[ end trace 4a930f0eb6428dcd ]---
[    4.909742] [drm] radeon: finishing device.

EDIT: Well, I feel like a damn fool. Got it working by applying the arbiter patches to the kernel. When I had checked the patches out I had wrongly assumed they were both intel graphics only patches and so weren't necessary. This doesn't seem to be the case with the vga_arbiter_fix though. Windows 8 running with graphics passthrough working beautifully. Going to play with graphics drivers a bit, get it updated to 8.1 and see what kinds of issues I am running into then, if any. Thanks for all of your hard work everyone!

Last edited by zerotri (2014-08-05 10:44:58)

HPvirt · 2014-08-05 20:06:58

slis wrote:

you need to bind device before u start vm, with systemd service or by hand (vfio-bind 0000:01:00.0 0000:01:00.1, assumin u created vfio-bind script as in first post)

I know this and I use vfio-bind script ... except the italic part. I know this question is off topic, so I've done some research.
This is what I found:
- Create the file (VFIOBindings.service for example) into /etc/systemd/system
- systemctl start VFIOBindings.service
- systemctl enable VFIOBindings.service
And that's all.
But I would be sure to avoid messing startup.

I progress... I assigned the ASMedia SATA controller with success.
The SSD is recognized by the live CD, and SMART works. Great!

Tried the ASMedia USB controller too with some succes: at VM boot time, the USB does not work, it's only when the live CD launch the keyboard and the mouse lights. Is there something wrong or is it normal?
This is my command line to launch qemu:

qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host -smp sockets=1,cores=2,threads=2 -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 \
-device vfio-pci,host=07:00.0,bus=pcie.0 \
-device vfio-pci,host=09:00.0,bus=pcie.0 \
[b]-device vfio-pci,host=0a:00.0,bus=pcie.0[/b] \
-device ahci,id=ahci0 \
-boot menu=on,oder=d \
-drive file=~/Linux/Mint/64/linuxmint-17-cinnamon-64bit-v2.iso,id=isocd \
-device ide-cd,bus=ide.1,drive=isocd

(bold is ASMedia USB Controller).

And now, the network part... I tried to passthrough the Realtek Ethernet Controller...
lspci gives me:

...
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)
...

So, vfio-bind 0000:03:00.0 then launch qemu with: -device vfio-pci,host=03:00.0,bus=pcie.0 -net none
And it works. I have the Realtek under liveCD and this one.

So, everything seems to work.
Second step done.

For the moment, options kvm allow_unsafe_assigned_interrupts=1 and pcie_acs_override=downstream are not used.

And now the last one: installing Windows!

CharlieBra7o · 2014-08-06 00:09:06

monchi wrote:

are the patches from #1 still needed for the recent stabel kernel version 3.16 ?

I'm using 3.16 RC7 and didn't have to patch the Intel stuff... Not sure about the other patches though.

shrubuntu · 2014-08-06 23:52:03

kameloc wrote:

shrubuntu wrote:
kameloc wrote:
I had this issue on Windows 8 and tried using different cards to emulate with no fix. Switched to Windows 7 and using ac97 (-sound ac97) works really well.
-device ac97,bus=pcie.0,addr=1b.0,id=sound0 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0
like this?
Oh sorry I don't passthrough my onboard audio, just share it. If you add
-soundhw ac97
It emulates Realtek AC'97 for the guest. It allowed me to use my speakers from the VM or host, and at the same time

Can you show me the whole command? I can't seem to get it to work

kameloc · 2014-08-07 00:48:22

shrubuntu wrote:

kameloc wrote:
shrubuntu wrote:
-device ac97,bus=pcie.0,addr=1b.0,id=sound0 \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0
like this?
Oh sorry I don't passthrough my onboard audio, just share it. If you add
-soundhw ac97
It emulates Realtek AC'97 for the guest. It allowed me to use my speakers from the VM or host, and at the same time
Can you show me the whole command? I can't seem to get it to work

This is how I start my VM. Only passthrough my GPU and a USB device. Emulate ac97 at the end.

sudo -E qemu-system-x86_64 -enable-kvm \
-M q35 \
-cpu host \
-smp 4,cores=4,threads=8,sockets=1 \
-m 6122 \
-rtc base=localtime,clock=host \
-balloon virtio \
-boot menu=on \
-bios /usr/share/qemu/bios.bin \
-vga none \
-usbdevice host:0d8c:0008 \
-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,romfile=/home/kameloc/windows7/EVGA.GTX550Ti.1024.121031.rom,multifunction=on,x-vga=on \
-device piix4-ide,bus=pcie.0,id=piix4-ide \
-drive file=/home/kameloc/windows7/windows7.img,id=disk,format=raw -device ide-hd,bus=piix4-ide.0,drive=disk \
-net nic,macaddr=DE:AD:BE:EF:00:00 \
-net bridge,br=br0 \
-soundhw ac97

HPvirt · 2014-08-07 08:21:41

slis wrote:

about ssd... i am not sure, but i think u need to pass whole sata controller to use trim etc...

With whole sata controller passed, I can start Win7 installation (copying file, uncompress), but at reboot time to finish installation, QEmu/SeaBios do not see the SSD anymore so cannot boot on it. If I try the installation from scratch once more, the installer see the SSD.

This is the qemu commande I used:

qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host -smp sockets=1,cores=2,threads=2 -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 \
-device vfio-pci,host=03:00.0,bus=pcie.0 \
-device vfio-pci,host=07:00.0,bus=pcie.0 \
-device vfio-pci,host=09:00.0,bus=pcie.0 \
-device vfio-pci,host=0a:00.0,bus=pcie.0 \
-boot menu=on,oder=d \
-drive file=~/Win7SP1.iso,id=isocd \
-device ide-cd,bus=ide.1,drive=isocd \
-net none

I have to add:

-usb \
-usbdevice host=xxxx:xxxx \
-usbdevice host=xxxx:xxxx \

for mouse and keyboard as ASMedia USB controller does not seem initialized by seabios (or qemu) at boot time, so cannot use them during Win7 installation.

So, I have 2 problems that I need help:
- USB initialization at boot
- SSD no more visible by qemu/seabios after first phase of Win7 installation

I've googled each problem, but I've not found anything valuable

sinny · 2014-08-07 18:19:35

HPvirt wrote:

slis wrote:
about ssd... i am not sure, but i think u need to pass whole sata controller to use trim etc...
With whole sata controller passed, I can start Win7 installation (copying file, uncompress), but at reboot time to finish installation, QEmu/SeaBios do not see the SSD anymore so cannot boot on it. If I try the installation from scratch once more, the installer see the SSD.
This is the qemu commande I used:
qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host -smp sockets=1,cores=2,threads=2 -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 \
-device vfio-pci,host=03:00.0,bus=pcie.0 \
-device vfio-pci,host=07:00.0,bus=pcie.0 \
-device vfio-pci,host=09:00.0,bus=pcie.0 \
-device vfio-pci,host=0a:00.0,bus=pcie.0 \
-boot menu=on,oder=d \
-drive file=~/Win7SP1.iso,id=isocd \
-device ide-cd,bus=ide.1,drive=isocd \
-net none
I have to add:
-usb \
-usbdevice host=xxxx:xxxx \
-usbdevice host=xxxx:xxxx \
for mouse and keyboard as ASMedia USB controller does not seem initialized by seabios (or qemu) at boot time, so cannot use them during Win7 installation.
So, I have 2 problems that I need help:
- USB initialization at boot
- SSD no more visible by qemu/seabios after first phase of Win7 installation
I've googled each problem, but I've not found anything valuable :(

maybe "-no-reboot" qemu parameter may serve you as a workaround?

Namelles_One · 2014-08-08 15:07:42

So, I was updated to qemu 2.1 on Gentoo and get input grabbing problems like in this thread

But I can't understand, how to fix it? Can I do this, or I will downgrade to qemu 2.0?

Thx.

irtimmer · 2014-08-08 18:39:44

I never know it was possible to grab the mouse and keyboard with -vga none in Qemu 2.0 as it also don't work in Qemu < 2.0. But a simple fix is to add
"-device qxl"

alexis_evo · 2014-08-09 11:31:34

Have a huge problem, no idea how to fix it, really need help as it makes a game I'm playing unplayable.

Final Fantasy XIV (an MMO) disconnects every hour. After spending ~8 hours trying to figure out why, I've narrowed it down to the cause but can't find a solution.

Every hour, the Windows VM's clock drifts to 3-4 minutes behind the real time. Windows detects this and fixes it. All applications that use the system clock then freak out as time just jumped forward 3-4 minutes, including FFXIV which causes you to disconnect.

The system time has changed to 2014-08-09T11:23:48.500000000Z from 2014-08-09T11:22:27.765200000Z.

This is the message shown in Windows Event Viewer, pointing out the change. I've tried adding two things to qemu to fix it.

-rtc clock=vm,base=localtime,driftfix=slew

-rtc base=utc,driftfix=slew

Neither of these have worked. The first one has worked the best, and has the drift down to 1 minute per hour, but that is still unacceptable and causes a disconnect. My computers RTC (in BIOS) is set to UTC time, and the time in Arch is changed via timezones to UTC-6 (MST).

Has anyone figured this out? kinda desperate, need my MMO fix lol.

aldum · 2014-08-09 11:48:32

alexis_evo wrote:

Has anyone figured this out? kinda desperate, need my MMO fix lol.

You could either try to make it refresh more often so it wouldn't jump as much at once, or turn off the automatic time correction altogether and update time by hand after quitting the game
Key to modify:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\W32Time\TimeProviders\NtpClient\SpecialPollInterval (seconds)

Namelles_One · 2014-08-09 15:06:45

irtimmer wrote:

I never know it was possible to grab the mouse and keyboard with -vga none in Qemu 2.0 as it also don't work in Qemu < 2.0. But a simple fix is to add
"-device qxl"

This don't help me. On Qemu 2.0 I was clicking on black window and my VM grab my input. How to do this with 2.1?

dwe11er · 2014-08-09 15:56:37

alexis_evo wrote:

Have a huge problem, no idea how to fix it, really need help as it makes a game I'm playing unplayable.
Final Fantasy XIV (an MMO) disconnects every hour. After spending ~8 hours trying to figure out why, I've narrowed it down to the cause but can't find a solution.
Every hour, the Windows VM's clock drifts to 3-4 minutes behind the real time. Windows detects this and fixes it. All applications that use the system clock then freak out as time just jumped forward 3-4 minutes, including FFXIV which causes you to disconnect.
The system time has changed to 2014-08-09T11:23:48.500000000Z from 2014-08-09T11:22:27.765200000Z.
This is the message shown in Windows Event Viewer, pointing out the change. I've tried adding two things to qemu to fix it.
-rtc clock=vm,base=localtime,driftfix=slew
-rtc base=utc,driftfix=slew
Neither of these have worked. The first one has worked the best, and has the drift down to 1 minute per hour, but that is still unacceptable and causes a disconnect. My computers RTC (in BIOS) is set to UTC time, and the time in Arch is changed via timezones to UTC-6 (MST).
Has anyone figured this out? kinda desperate, need my MMO fix lol.

I've stumbled upon this issue, when all of hosts cores/threads where assigned to vm. Host was doing something in the background, while I was playing on Windows.

alexis_evo · 2014-08-09 19:24:28

aldum wrote:

alexis_evo wrote:
Has anyone figured this out? kinda desperate, need my MMO fix lol.
You could either try to make it refresh more often so it wouldn't jump as much at once, or turn off the automatic time correction altogether and update time by hand after quitting the game
Key to modify:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\W32Time\TimeProviders\NtpClient\SpecialPollInterval (seconds)

I appreciate the help, but I don't think the issue is NTP. I've already disabled NTP in Windows. It's my understanding that there's three clocks on a computer. The RTC (hardware level, set in BIOS, battery backed), the system time (low level, set by the RTC on boot, never changes, used for timing by games/etc), and the local clock (the time displayed, synced by NTP). The problem is the system time is drifting off of the RTC. Windows checks it every hour and sees how much it has drifted, then snaps it back into place. XIV expects this time to never ever change, so it messes seriously with the ping thread/connection.

dwe11er wrote:

I've stumbled upon this issue, when all of hosts cores/threads where assigned to vm. Host was doing something in the background, while I was playing on Windows.

I don't see why the # of cores would matter, Windows isn't eating up all available CPU time, but I'll try dropping it down to 7 cores anyway. Also tried adding "hv-time" to "-cpu host, hv-time", as it looks like that should fix it. I guess time will tell...

Last edited by alexis_evo (2014-08-09 19:24:45)

abdullah · 2014-08-09 19:27:21

Is the KVM=off applied in Qemu 2.1.0 ? it was released 8 days ago, do I still need the Qemu-git ?
And I did compile the Qemu-git, yet I receive BSOD in windows, and I can not pass the USB devices with -usb -usbdevice host:*:* anymore.

alexis_evo · 2014-08-09 20:07:56

Still happening.

The system time has changed to 2014-08-09T20:07:47.500000000Z from 2014-08-09T20:05:54.641000000Z.

dwe11er · 2014-08-09 22:17:42

alexis_evo wrote:

aldum wrote:
alexis_evo wrote:
Has anyone figured this out? kinda desperate, need my MMO fix lol.
You could either try to make it refresh more often so it wouldn't jump as much at once, or turn off the automatic time correction altogether and update time by hand after quitting the game
Key to modify:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\W32Time\TimeProviders\NtpClient\SpecialPollInterval (seconds)
I appreciate the help, but I don't think the issue is NTP. I've already disabled NTP in Windows. It's my understanding that there's three clocks on a computer. The RTC (hardware level, set in BIOS, battery backed), the system time (low level, set by the RTC on boot, never changes, used for timing by games/etc), and the local clock (the time displayed, synced by NTP). The problem is the system time is drifting off of the RTC. Windows checks it every hour and sees how much it has drifted, then snaps it back into place. XIV expects this time to never ever change, so it messes seriously with the ping thread/connection.
dwe11er wrote:
I've stumbled upon this issue, when all of hosts cores/threads where assigned to vm. Host was doing something in the background, while I was playing on Windows.
I don't see why the # of cores would matter, Windows isn't eating up all available CPU time, but I'll try dropping it down to 7 cores anyway. Also tried adding "hv-time" to "-cpu host, hv-time", as it looks like that should fix it. I guess time will tell...

It's because of load on every core host can't keep up with clock emulation. I'm guessing here.

alexis_evo · 2014-08-09 22:28:49

CPU has 8 cores, at most I'm ever using 300%. There's more than enough CPU time on the host to do things it needs. I lowered Windows to 7 cores and it still drifts. I've tried a couple different options now and it still drifts. It's annoying as it takes an hour to test every time, as it takes an hour for Windows to pick up on the drift and adjust system time. Should know in a couple of minutes if the latest incantation worked...

aldum · 2014-08-09 22:31:39

alexis_evo wrote:

I appreciate the help, but I don't think the issue is NTP. I've already disabled NTP in Windows. It's my understanding that there's three clocks on a computer. The RTC (hardware level, set in BIOS, battery backed), the system time (low level, set by the RTC on boot, never changes, used for timing by games/etc), and the local clock (the time displayed, synced by NTP). The problem is the system time is drifting off of the RTC.

Ok, so you tried turning it off, now try the other way: have it update every 5 minutes.

Arch Linux

#2426 2014-08-04 15:42:49

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

#2427 2014-08-04 15:46:41

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

#2428 2014-08-04 19:17:49

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

#2429 2014-08-04 22:27:39

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

#2430 2014-08-05 05:38:52

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

#2431 2014-08-05 06:29:29

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

#2432 2014-08-05 08:01:54

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

#2433 2014-08-05 20:06:58

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

#2434 2014-08-06 00:09:06

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

#2435 2014-08-06 23:52:03

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

#2436 2014-08-07 00:48:22

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

#2437 2014-08-07 08:21:41

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

#2438 2014-08-07 18:19:35

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

#2439 2014-08-08 15:07:42

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

#2440 2014-08-08 18:39:44

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

#2441 2014-08-09 11:31:34

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

#2442 2014-08-09 11:48:32

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

#2443 2014-08-09 15:06:45

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

#2444 2014-08-09 15:56:37

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

#2445 2014-08-09 19:24:28

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

#2446 2014-08-09 19:27:21

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

#2447 2014-08-09 20:07:56

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

#2448 2014-08-09 22:17:42

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

#2449 2014-08-09 22:28:49

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

#2450 2014-08-09 22:31:39

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

Board footer