linux-kernel - Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Jul 2016 15:16:21 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Eduardo Habkost <ehabkost@...hat.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX



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@...ux.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@...ux.intel.com>
    Reviewed-by: Richard Henderson <rth@...ddle.net>
    Signed-off-by: Eduardo Habkost <ehabkost@...hat.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?
>