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.odaki@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.