Hi, On 2/2/24 11:51, 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. 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 Yes in general migrating to different kernels will fail. Same for different pCPU types. We need CPU models to work around some of those limitations. Adding Sebastian in copy. He is currently working on this.
Thanks Eric > 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 >
