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@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Reviewed-by: Richard Henderson <rth@xxxxxxxxxxx>
Signed-off-by: Eduardo Habkost <ehabkost@xxxxxxxxxx>
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?
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html