On Thu, Aug 08, 2024 at 08:32:58PM +0900, Akihiko Odaki wrote: > On 2024/08/08 20:12, Michael S. Tsirkin wrote: > > On Thu, Aug 08, 2024 at 08:03:25PM +0900, Akihiko Odaki wrote: > > > On 2024/08/08 19:54, Michael S. Tsirkin wrote: > > > > On Thu, Aug 08, 2024 at 07:52:37PM +0900, Akihiko Odaki wrote: > > > > > On 2024/08/06 22:29, Michael S. Tsirkin wrote: > > > > > > On Tue, Aug 06, 2024 at 04:35:44PM +0900, Akihiko Odaki wrote: > > > > > > > On 2024/08/05 19:08, Michael S. Tsirkin wrote: > > > > > > > > On Mon, Aug 05, 2024 at 06:37:58PM +0900, Akihiko Odaki wrote: > > > > > > > > > If cross-migrate=off, QEMU can still migrate on the same host (checkpoint > > > > > > > > > and restart). QEMU can also migrate across hosts if the user ensures they > > > > > > > > > are on the same platform. > > > > > > > > > > > > > > > > What is so special about checkpoint/restart? I guess we hope that > > > > > > > > downgrades are uncommon, but they are possible... > > > > > > > > > > > > > > Downgrades will not work with cross-migrate=off. Users who want downgrades > > > > > > > should use cross-migrate=on. > > > > > > > > > > > > We also don't know that upgrades do not disable a feature: > > > > > > can happen if e.g. there's a serious bug in the feature. > > > > > > Basically, this makes the feature too fragile, in my opinion. > > > > > > > > > > We can do nothing in such a case. Whether it is on a single host or multiple > > > > > hosts, we cannot support migration if features once enabled disappear. > > > > > > > > > > Regards, > > > > > Akihiko Odaki > > > > > > > > It does not follow that we have to do something, and this is something, > > > > therefore that we have to do this. > > > > > > > > This is just a reason not to handle checkpoint/restart any different > > > > than any other migration. > > > > > > Whethere it is checkpoint/restart or any other migration, I expect platform > > > features won't disappear from the host(s); we can't readily support > > > migration in such a situation. > > > > > > We can if we mask the features from the guest before starting VM. > > > > Or if we didn't, we can fail gracefully. > > > > > When platform features won't disappear, for checkpoint/restart, we can > > > enable all available features without disrupting migration; > > > cross-migrate=off will instruct that. > > > > > > However, if we are migrating a VM across hosts and the user doesn't ensure > > > they are on the same platform, we cannot enable platform features even if we > > > are sure that platform features already present on a host won't disappear > > > because some hosts may not have features in the first place. We can set > > > cross-migrate=on in such a case to disable optional platform features. > > > > > > Regards, > > > Akihiko Odaki > > > > > > This is too big of a hammer. People already use what you call "cross > > migrate" and have for years. We are not going to stop developing > > features just because someone suddenly became aware of some such bit. > > If you care, you will have to work to solve the problem properly - > > nacking half baked hacks is the only tool maintainers have to make > > people work on hard problems. > > I think you meant cross-migrate=off, which is the current behavior. > > I am not suggesting forcing cross-migrate=on or even making it default. I > have shown four possible scenarios earlier[a]: > > 1) Migration everywhere > 2) Migration on specific machines > 3) Migration on some known platforms > 4) No migration (migration on nowhere) > > Taking the discussion with Peter, I amend 4) as follows: > 4*) Migration on one platform (checkpoint/restore) Maybe we can avoid calling out "checkpoint/restore", but something like "migration on identical hosts" or something. AFAIU that's what we do with many arm64 systems on the vcpu models with KVM (IIRC it's still about using "virt" machines), where we simply mostly require it's the identical bare metal host or weird things can happen when migration happens. > > cross-migrate=on is a complete solution for 1). > 2) is dealt with another proposal of mine.[b] > 3) can be solved with the -platform proposal by Daniel.[c] > 4*) is what QEMU currently implements. > > [a] > https://lore.kernel.org/all/39a8bb8b-4191-4f41-aaf7-06df24bf3280@xxxxxxxxxx/ > [b] > https://lore.kernel.org/all/2da4ebcd-2058-49c3-a4ec-8e60536e5cbb@xxxxxxxxxx/ > [c] https://lore.kernel.org/all/ZqO7cR-UiGpX2rk0@xxxxxxxxxx/ > > Regards, > Akihiko Odaki > Thanks, -- Peter Xu
