On Mon, Dec 10, 2018 at 07:13:28PM +0100, Borislav Petkov wrote: > Reviving an old thread here. > > On Wed, Jul 06, 2016 at 11:27:16PM +0200, Paolo Bonzini wrote: > > On 06/07/2016 19:34, Eduardo Habkost wrote: > > >> > Nothing is needed in the kernel actually. You can skip the intercept > > >> > by running the guest with MSR_TSC_AUX set to the guest's expected value. > > >> > Which KVM does, except that it's botched so I need to apply the > > >> > patch in https://lkml.org/lkml/2016/4/13/802. > > > Do you mean -cpu Opteron_G*,+rdtscp will be buggy on Linux v4.5? > > > (v4.5 reports rdtscp as supported in GET_SUPPORTED_CPUID) > > > > > > Can we do something to make QEMU detect the buggy kernel before > > > allowing rdtscp to be enabled, or should we just tell people to > > > upgrade their kernel? > > > > We usually just tell people to use the latest stable kernel. > > > > Adding new CPU models is not a big deal, in fact it's almost easier than > > getting compat properties right. :) > > Ok, can we finally revert > > 33b5e8c03ae7 ("target-i386: Disable rdtscp on Opteron_G* CPU models") > > in the qemu tree? > > Three years should be enough by now for > > 46896c73c1a4 ("KVM: svm: add support for RDTSCP") > > to have percolated downstream. That's Linux v4.5, released in March 2016. It isn't as simply as reverting commit 33b5e8c03ae7, but we can surely re-add RDTSCP on pc-*-4.0 and newer. I thought we added documentation mentioning the minimum kernel version required by QEMU, but I can't find it. In either case, it seems reasonable to require Linux 4.5 or newer on newer machine-types. -- Eduardo
