On Mon, 5 Feb 2024 at 02:56, Peter Xu <pet...@redhat.com> wrote: > 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.
It just hasn't been anything that anybody so far has wanted enough to put the necessary kernel-side work into. (There are also some tricky issues surrounding errata workarounds that the guest needs to do: you need to have some way of telling the guest "the vCPU looks like it's type X but you need to do errata workarounds ABC for CPU type Y, not the ones for X".) > > 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). That seems a bit pessimistic. How about "always only test with TCG" ? That will defend the migration compat on all the device models etc, which is the bit we're most likely to break by accident. thanks -- PMM
