On Fri, Feb 02, 2024 at 10:51:36AM +0000, Peter Maydell wrote: > 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.
Thanks, but then this is pretty sad. I'm surprised aarch64 doesn't have such requirement to allow some VM config to run across all kinds of hosts. > 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.) Yes we don't have issue for the current CI on KVM compatibilities, but QEMU does matter for sure. Then we can either (1) add code as Fabiano suggested to choose different cpu model by adding hack code in qtest, or (2) we simply not support aarch64 on cross binary test like most of the rest of the arch, but only support x86, until any arch can provide a stable CPU that support all config of hosts (we can document it in the CI file). I'd vote for (2). Fabiano, do you have any preference? -- Peter Xu
