From: Borislav Petkov <bp@alien8.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX
Date: Thu, 7 Jul 2016 14:47:12 +0200 [thread overview]
Message-ID: <20160707124712.GE13648@pd.tnic> (raw)
In-Reply-To: <8c66c2b5-58fe-7384-31a3-f6f784461ca6@redhat.com>
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?
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?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
next prev parent reply other threads:[~2016-07-07 12:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 13:43 [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini
2016-07-06 14:18 ` Borislav Petkov
2016-07-06 14:29 ` Paolo Bonzini
2016-07-07 10:41 ` Borislav Petkov
2016-07-07 11:01 ` Paolo Bonzini
2016-07-07 11:47 ` Borislav Petkov
2016-07-07 12:28 ` Paolo Bonzini
2016-07-07 12:47 ` Borislav Petkov [this message]
2016-07-07 13:16 ` Paolo Bonzini
2016-07-07 16:01 ` Borislav Petkov
2016-07-07 16:17 ` Paolo Bonzini
2016-07-07 16:27 ` Eduardo Habkost
2016-07-07 17:04 ` Borislav Petkov
2016-07-07 17:43 ` Eduardo Habkost
2016-07-08 11:09 ` Borislav Petkov
2016-07-08 11:15 ` Paolo Bonzini
2016-07-08 12:55 ` Borislav Petkov
2016-07-06 15:00 ` kbuild test robot
2016-07-15 12:15 ` Radim Krčmář
2016-07-15 12:30 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160707124712.GE13648@pd.tnic \
--to=bp@alien8.de \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox