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.
--
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