Hi Martin,
Am 04.10.2016 10:09, schrieb Martin Schrodt:
Hi Hristo,
No need to sleep/wake - my X99-based system starts with TSC disabled:
$ dmesg | grep TSC
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.077986] TSC deadline timer enabled
[ 0.203383] TSC synchronization [CPU#0 -> CPU#1]:
[ 0.203384] Measured 974558547804462 cycles TSC warp between CPUs,
turning off TSC clock.
[ 0.203388] tsc: Marking TSC unstable due to check_tsc_sync_source
failed
Consequently, tsc is not among the clock sources listed in
available_clocksource. KVM is not happy about that:
[16739.200656] kvm: SMP vm created on host with unstable TSC; guest
TSC
will not be reliable
Ok, so an X99-board that behaves like this even on a fresh start.
Interesting.
But I haven't observed any instabilities of the Windows 10 guest,
which
happily runs with 4 virtual CPUs (2 virtual hyperthreaded CPUs) bound
to
two cores of my i7-5820K.
This really makes me think there's something else involved in this
behaviour. Maybe the CPU configuration (I use "Skylake-Client") exposes
TSC to the guest, so if you put that on, it'll use it?
Can you check what kind of virtual CPU you use?
I use 'passthrough', otherwise the default 'Haswell-noTSX' that
virt-manager picks results in NVIDIA GeForce Experience complaining
about unrecognised CPU type, so the TSC gets pretty much exposed to the
guest.
Just found this paste with a boot log from another system with the same
motherboard, though with an older BIOS version and a Xeon E5-1620 v3
CPU:
https://pastelink.net/fjm
It shows the same problem with unsynchronised TSCs. Could also be
something specific to the LGA 2011v3 processors or to the EFI BIOS. I'll
take a look in the BIOS options when time permits.
Cheers,
Martin
Cheers,
Hristo
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
