On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote: > On Tue, Jul 30, 2024 at 04:03:53PM -0400, Peter Xu wrote: > > On Tue, Jul 30, 2024 at 03:22:50PM -0400, Michael S. Tsirkin wrote: > > > This is not what we did historically. Why should we start now? > > > > It's a matter of whether we still want migration to randomly fail, like > > what this patch does. > > > > Or any better suggestions? I'm definitely open to that. > > > > Thanks, > > > > -- > > Peter Xu > > Randomly is an overstatement. You need to switch between kernels > where this feature differs. We did it with a ton of features > in the past, donnu why we single out USO now. Right, my previous comment should apply to all such features, so it's not sololy about USO*. For old features that Jason mentioned that can also be auto-OFF, my wild guess was that most of them should be supported in most of the kernels that people are using, so they're fine. Otherwise I don't see what stops it from happening in other features too. And that's also why I am thinking maybe we don't need to fix old features, but for this USO* one - I'm not sure yet; it could hit already. For the future, I definitely want to avoid such issue; that's also one major reason / goal I wanted to discuss this thoroughly this time.. > > Basically downstreams just don't separately add kernel features vs > qemu features. There's little reason for them to do so. But we hit this bug in downstream tests.. IIUC it means this is not the case? To be explicit, for RHEL9 some version we added USO* features for QEMU, but not yet for the kernel TAP drivers. AFAIU that's the context where we trapped this failure where we have some system supporting the QEMU feature but not supporting the kernel ones. While some newer systems will support both. Then we hit this when migrating back to the RHEL9 system. Thanks, -- Peter Xu
