Probably we mix two different patches in this discussion. Focusing on the patch in the e-mail header:
IMO it is not acceptable to fail QEMU run for one feature that we can't make active when we silently drop all other features in such a case. On Wed, Nov 1, 2023 at 11:15 AM Akihiko Odaki <akihiko.od...@daynix.com> wrote: > On 2023/11/01 18:09, Michael S. Tsirkin wrote: > > On Wed, Nov 01, 2023 at 05:35:50PM +0900, Akihiko Odaki wrote: > >> On 2023/11/01 15:38, Michael S. Tsirkin wrote: > >>> On Wed, Nov 01, 2023 at 01:50:00PM +0900, Akihiko Odaki wrote: > >>>> We had another discussion regarding migration for patch "virtio-net: > Do not > >>>> clear VIRTIO_NET_F_HASH_REPORT". It does change the runtime behavior > so we > >>>> need to take migration into account. I still think the patch does not > >>>> require a compatibility flag since it only exposes a new feature and > does > >>>> not prevent migrating from old QEMU that exposes less features. It > instead > >>>> fixes the case where migrating between hosts with different tap > feature > >>>> sets. > >>> > >>> When in doubt, add a compat flag. > >> > >> Personally I'm confident about the migration compatibility with patch > >> "virtio-net: Do not clear VIRTIO_NET_F_HASH_REPORT". virtio-net already > does > >> the same thing when the tap implementation on the destination implements > >> virtio-net header support while the counterpart of the source does not. > > > > Trust me there's been so many times where we were very sure and > > problems come up later. Just don't enable new functionality for > > old machine types, problem solved. Why is this hard? > > I see. I'll add a compatibility flag for VIRTIO_NET_F_HASH_REPORT > exposure; it should be quite easy. >
