public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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