From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754157AbcGFNBL (ORCPT ); Wed, 6 Jul 2016 09:01:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37318 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751919AbcGFNBJ (ORCPT ); Wed, 6 Jul 2016 09:01:09 -0400 Subject: Re: kvm: RDTSCP on AMD To: Borislav Petkov , Eduardo Habkost References: <20160706124438.GB7300@pd.tnic> Cc: =?UTF-8?B?SsO2cmcgUsO2ZGVs?= , Andre Przywara , kvm ML , lkml From: Paolo Bonzini Message-ID: Date: Wed, 6 Jul 2016 15:01:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160706124438.GB7300@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 06 Jul 2016 13:01:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > --- > > 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? Paolo