Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1438599
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX |
| Date | 2016-07-07 15:00 +0200 |
| Message-ID | <rSh4m-71b-49@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <rRVZT-1T1-3@gated-at.bofh.it> <rSf2y-5Kz-35@gated-at.bofh.it> <rSflU-66A-29@gated-at.bofh.it> <rSfYB-6lM-13@gated-at.bofh.it> <rSgBk-6Qy-25@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini <pbonzini@redhat.com> - 2016-07-06 15:50 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Borislav Petkov <bp@alien8.de> - 2016-07-06 16:20 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini <pbonzini@redhat.com> - 2016-07-06 16:30 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Borislav Petkov <bp@alien8.de> - 2016-07-07 12:50 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini <pbonzini@redhat.com> - 2016-07-07 13:10 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Borislav Petkov <bp@alien8.de> - 2016-07-07 13:50 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini <pbonzini@redhat.com> - 2016-07-07 14:30 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Borislav Petkov <bp@alien8.de> - 2016-07-07 15:00 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini <pbonzini@redhat.com> - 2016-07-07 15:20 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Borislav Petkov <bp@alien8.de> - 2016-07-07 18:10 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini <pbonzini@redhat.com> - 2016-07-07 18:20 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Eduardo Habkost <ehabkost@redhat.com> - 2016-07-07 18:30 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Borislav Petkov <bp@alien8.de> - 2016-07-07 19:10 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Eduardo Habkost <ehabkost@redhat.com> - 2016-07-07 19:50 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Borislav Petkov <bp@alien8.de> - 2016-07-08 13:10 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Paolo Bonzini <pbonzini@redhat.com> - 2016-07-08 13:20 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX Borislav Petkov <bp@alien8.de> - 2016-07-08 15:00 +0200
Re: [PATCH] KVM: SVM: fix trashing of MSR_TSC_AUX kbuild test robot <lkp@intel.com> - 2016-07-06 17:10 +0200
csiph-web