From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755515AbcGFRfl (ORCPT ); Wed, 6 Jul 2016 13:35:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36223 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754706AbcGFReo (ORCPT ); Wed, 6 Jul 2016 13:34:44 -0400 Date: Wed, 6 Jul 2016 14:34:40 -0300 From: Eduardo Habkost To: Paolo Bonzini Cc: Borislav Petkov , =?iso-8859-1?Q?J=F6rg_R=F6del?= , Andre Przywara , kvm ML , lkml Subject: Re: kvm: RDTSCP on AMD Message-ID: <20160706173440.GU4131@thinpad.lan.raisama.net> References: <20160706124438.GB7300@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fnord: you can see the fnord User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 06 Jul 2016 17:34:43 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 06, 2016 at 03:01:04PM +0200, Paolo Bonzini wrote: > On 06/07/2016 14:44, Borislav Petkov wrote: > > Hi guys, > > > > how about this below to enable RDTSCP emulation on AMD? IOW, I'm staring > > at > > > > 33b5e8c03ae7 ("target-i386: Disable rdtscp on Opteron_G* CPU models") > > > > in the qemu repo. > > > > It seems to work here, RDTSCP in the guest gives me node and cpu as > > vsyscall_set_cpu() in the guest kernel has set them. > > > > Thoughts? > > > > (Below is the simple qemu diff reenabling RDTSCP) > > > > @@ -3919,6 +3935,7 @@ static int (*const svm_exit_handlers[])(struct vcpu_svm *svm) = { > > [SVM_EXIT_STGI] = stgi_interception, > > [SVM_EXIT_CLGI] = clgi_interception, > > [SVM_EXIT_SKINIT] = skinit_interception, > > + [SVM_EXIT_RDTSCP] = rdtscp_interception, > > [SVM_EXIT_WBINVD] = wbinvd_interception, > > [SVM_EXIT_MONITOR] = monitor_interception, > > [SVM_EXIT_MWAIT] = mwait_interception, > > 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? > > > --- > > > > qemu diff: > > > > --- > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > > index 3bd3cfc3ad16..aa6d0d027d00 100644 > > --- a/target-i386/cpu.c > > +++ b/target-i386/cpu.c > > This is not enough because it's missing some backwards compatibility > gunk (similar to the include/hw/i386/pc.h parts of 33b5e8c03ae), but > it's enough for a proof of concept and to discuss it. > > The main issue with this is that it would force a lockstep update of > QEMU and kernel, which we try to avoid. I'm not sure if we have a > solution for this problem. Eduardo? We don't. Either we make QEMU require a newer kernel, or we need a new CPU model. :( -- Eduardo