From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752187AbcGGNQg (ORCPT <rfc822;w@1wt.eu>);
	Thu, 7 Jul 2016 09:16:36 -0400
Received: from mail-wm0-f66.google.com ([74.125.82.66]:34300 "EHLO
	mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750867AbcGGNQ1 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 7 Jul 2016 09:16:27 -0400
Subject: Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX
To: Borislav Petkov <bp@alien8.de>
References: <1467812596-18903-1-git-send-email-pbonzini@redhat.com>
 <20160706141847.GF7300@pd.tnic>
 <361b792f-87ce-863d-5098-9a18aadd6379@redhat.com>
 <20160707104128.GC13648@pd.tnic>
 <128bb0be-e597-32c0-f113-9fe02c257790@redhat.com>
 <20160707114717.GD13648@pd.tnic>
 <8c66c2b5-58fe-7384-31a3-f6f784461ca6@redhat.com>
 <20160707124712.GE13648@pd.tnic>
Cc: Eduardo Habkost <ehabkost@redhat.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org, stable@vger.kernel.org
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <21b7a239-5fac-b6bf-a48f-71fa456a9c97@redhat.com>
Date: Thu, 7 Jul 2016 15:16:21 +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: <20160707124712.GE13648@pd.tnic>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On 07/07/2016 14:47, Borislav Petkov wrote:
> On Thu, Jul 07, 2016 at 02:28:29PM +0200, Paolo Bonzini wrote:
>> Because otherwise you couldn't do live migration from new QEMU + new
>> kernel to new QEMU + old kernel.  QEMU tries to avoid requiring lockstep
>> upgrades of QEMU and KVM (unlike for example perf).
> 
> Hmm, ok.
> 
> About that - and I've asked about it a couple of times already - how
> would you guys feel about a testing feature to qemu - something I'd love
> to have with which I can set arbitrary CPUID bits for testing kernels?

Eduardo is the one to answer, but usually we add features to QEMU 
before the processors are released (typically as soon as KVM supports 
them).  So with a new enough QEMU this in theory should not be 
necessary.

Adding a new feature that's not in a CPU model and that's not 
associated to new state is really trivial:

commit f7fda280948a5e74aeb076ef346b991ecb173c56
Author: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Date:   Thu Oct 29 15:31:39 2015 +0800

    target-i386: Enable clflushopt/clwb/pcommit instructions
    
    These instructions are used by NVDIMM drivers and the specification is
    located at:
    https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
    
    There instructions are available on Skylake Server.
    
    Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
    Reviewed-by: Richard Henderson <rth@twiddle.net>
    Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 090d1d8..0d080c1 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -259,8 +259,8 @@ static const char *svm_feature_name[] = {
 static const char *cpuid_7_0_ebx_feature_name[] = {
     "fsgsbase", "tsc_adjust", NULL, "bmi1", "hle", "avx2", NULL, "smep",
     "bmi2", "erms", "invpcid", "rtm", NULL, NULL, "mpx", NULL,
-    "avx512f", NULL, "rdseed", "adx", "smap", NULL, NULL, NULL,
-    NULL, NULL, "avx512pf", "avx512er", "avx512cd", NULL, NULL, NULL,
+    "avx512f", NULL, "rdseed", "adx", "smap", NULL, "pcommit", "clflushopt",
+    "clwb", NULL, "avx512pf", "avx512er", "avx512cd", NULL, NULL, NULL,
 };

Paolo

> I.e., something like that:
> 
> qemu ... -cpu=Opteron_G5,cpuid_leaf=<bla>,eax=<..>,ebx=<...>, ...,filter=off
> 
> The filter=off thing is to disable the checking in
> x86_cpu_filter_features() so that those arbitrary CPUID leafs are
> actually simulated to the guest.
> 
> Would something like that make sense for upstream or should I hack it in
> locally only?
> 
> Because it sure does help a lot when testing kernel features for
> unreleased CPUs but for which the code is already being submitted. And
> with a qemu feature like that, we could at least smoke-test those a bit.
> 
> Hmmm?
>