I can confirm that GFE doesn't care if the CPU doesn't match what the physical CPU offers in terms of cores. My i5-4670k is chugging along just fine with 3 cores, as far as Windows knows.
On Tue, Oct 4, 2016 at 3:42 PM, Hristo Iliev <hri...@hiliev.eu> wrote: > Am 04.10.2016 18:32, schrieb Brett Peckinpaugh: > > What are you settling that fixes the Nvidia experience complaint? >> >> > In the domain description: > > <cpu mode='host-passthrough'> > <topology sockets='1' cores='2' threads='2'/> > </cpu> > > And ignore_msrs=1 in the options to the kvm kernel module. > > Apparently NVIDIA GFE is happy with i7-5820K having only two cores. > > Cheers, > Hristo > > On October 4, 2016 9:15:56 AM PDT, Hristo Iliev <hri...@hiliev.eu> wrote: >>> >>> 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 >
_______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
