On Thu, 1 Feb 2024 at 23:50, Peter Xu <pet...@redhat.com> wrote: > > Fabiano, I think you forgot to reply-to-all.. adding back the list and > people in the loop. > > On Thu, Feb 01, 2024 at 10:12:44AM -0300, Fabiano Rosas wrote: > > Peter Xu <pet...@redhat.com> writes: > > > > > On Wed, Jan 31, 2024 at 10:09:16AM -0300, Fabiano Rosas wrote: > > >> If we ask for KVM and it falls back to TCG, we need a cpu that supports > > >> both. We don't have that. I've put some command-line combinations at the > > >> end of the email[1], take a look. > > > > > > Thanks a lot, Fabiano. I think I have a better picture now. > > > > > > Now the question is whether it'll be worthwhile we (migration) explicitly > > > provide code to workaround such issue in qtest, or we wait for ARM side > > > until we have a processor that can be both stable and support KVM+TCG. > > > > > > I actually personally prefer to wait - it's not too bad after all, because > > > it only affects the new "n-1" migration test. Most of the migration > > > functionality will still be covered there in CI for ARM. > > > > That's fine with me. We just need to do something about the arm CI job > > which is currently disabled waiting for a fix. We could remove it or add > > some words somewhere explaining the situation. I can do that once we > > reach an agreement here. > > Yes. IMHO we can keep the test (with SKIPPED=1) but amend the message, > which will start to state inaccurately: > > # This job is disabled until we release 9.0. The existing > # migration-test in 8.2 is broken on aarch64. The fix was already > # commited, but it will only take effect once 9.0 is out. > > IMHO then it won't mean 9.0 will have it fixed, but we'll simply wait for a > cpu model that is ready for both kvm+tcg, then we replace "max".
We already have a CPU model that works for both KVM and TCG: that is "max". We're not going to add another one. The difference is just that we provide different cross-version migration compatibility support levels for the two cases. (Strictly speaking, I'm not sure we strongly support migration compat for 'max' on KVM either -- for instance you probably need to be doing a migration on the same host CPU type and the same host kernel version. It's just that the definition of "max" on KVM is less QEMU-dependent and more host-kernel-dependent, so in your particular situation running the test cases you're less likely to see any possible breakage.) -- PMM
