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