On Thu, Aug 08, 2024 at 10:47:28AM -0400, Michael S. Tsirkin wrote: > On Thu, Aug 08, 2024 at 10:15:36AM -0400, Peter Xu wrote: > > On Thu, Aug 08, 2024 at 07:12:14AM -0400, Michael S. Tsirkin wrote: > > > 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. > > > > IMHO this is totally different thing. It's not about proposing a new > > feature yet so far, it's about how we should fix a breakage first. > > > > And that's why I think we should fix it even in the simple way first, then > > we consider anything more benefitial from perf side without breaking > > anything, which should be on top of that. > > > > Thanks, > > As I said, once the quick hack is merged people stop caring.
IMHO it's not a hack. It's a proper fix to me to disable it by default for now. OTOH, having it ON always even knowing it can break migration is a hack to me, when we don't have anything else to guard the migration. > Mixing different kernel versions in migration is esoteric enough for > this not to matter to most people. There's no rush I think, address > it properly. Exactly mixing kernel versions will be tricky to users to identify, but that's, AFAICT, exactly happening everywhere. We can't urge user to always use the exact same kernels when we're talking about a VM cluster. That's why I think allowing migration to work across those kernels matter. I will agree there's no rush iff RHEL9 kernel won't backport TAP at all, otherwise this will trigger between y-stream after people upgrades partial of the clusters. Thanks, -- Peter Xu
