On 3/18/21 12:21 PM, Peter Maydell wrote: > On Thu, 18 Mar 2021 at 11:09, Philippe Mathieu-Daudé <phi...@redhat.com> > wrote: >> Still, I'm not sure it makes sense. If you want to migrate a such >> machine, KVM can not virtualize it, so you'll be forced to use TCG >> right? In that case cpu_tcg is built in and you have the A15. >> >> IOW the problem is not this patch, it is that since 82bf7ae84ce we >> can not migrate A15. > > Do you mean "we can't migrate a TCG A15" ? That would be a problem.
No problem here. > Or do you mean "we can't migrate a KVM A15" ? That's entirely > expected when we drop support for KVM A15 :-) Yes, this is why I mentioned this is mostly a problem for downstream distributions. > Or do you mean "migration from KVM to TCG doesn't work?" That's > a pre-existing thing I don't expect to work (we don't put anything > in to stop it working, but I'm pretty sure there will be a bunch > of things that mean it doesn't in practice work.) > >> So we need both 1/ revert 82bf7ae84ce and 2/ be sure the kernel >> support 32-bit host... Am I missing something? > > We're definitely not reverting 82bf7ae84ce if we can avoid it... I tend to agree. The problem is for the running VMs started before 82bf7ae84ce (so up to any fork based on v5.2). I don't know what the forks are supposed to do with the running VMs if they want to migrate them to newer QEMU (or upgrade the host QEMU). I don't expect a guest being happy and reliable if we underneath change its CPU by another one while migrating it... KVM to TCG is not tested much indeed, and I don't think the performance impact will be well accepted :)
