Re: [PATCH v2 1/3] hw/net: e1000: Correct the initial value of VET register

[Peter Maydell]

On Wed, 14 Jul 2021 at 04:42, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <jasowang@redhat.com> wrote:
> >
> >
> > 在 2021/7/13 下午5:11, Bin Meng 写道:
> > > Can we get some agreement among maintainers?
> >
> >
> > It's not about the agreement but about to have a stable ABI. I don't
> > know the case for sd but e1000 is used in various  and we work hard to
> > unbreak the migration compatibility among downstream versions. Git log
> > on e1000.c will tell you more.
>
> Agreement or stable ABI, whatever we call, but we should be in some 
> consistency.
>
> IMHO maintainers should reach an agreement to some extent on how
> compatibility should be achieved. I just found silly to add a property
> to fix a real bug in the model, and we preserve the bug all over
> releases.
>
> I can find plenty of examples in the current QEMU tree that were
> accepted that changed the bugous register behavior, but it was not
> asked to add new properties to keep the bugos behavior.
>
> e.g.: commit ce8e43760e8e ("hw/net: fsl_etsec: Reverse the RCTRL.RSF logic")

There is basically a judgement call going on here about whether the
device is "significant enough" that it's worth the effort of
preserving back-compatibility of bugs.

There is at least one clear rule: if the device isn't used by any
machine with a versioned machine type, then there is no need to
provide back-compatibility of old buggy behaviour. (There would
be no way for the user to select the old behaviour by choosing a
-4.2 machine type.) This is why the fsl_etsec device doesn't need
to handle that.

For PCI devices it's a bit fuzzier because in theory you can plug
any PCI card into a versioned x86 PC machine.

We don't want to preserve bug-compatibility for absolutely
everything, because the codebase would quickly clog up with weird
behaviour that we never test and which is not of any use to users
either. So you have to look at:
 * how easy is providing the back-compat?
 * how commonly used in production is the device?
 * how likely is it that guests might care?
 * would the behaviour change cause odd behaviour across
   a cross-version migration from the old QEMU?

Migration compat is similar, but not quite the same because the
compatibility handling tends to be less invasive, so we take the
"provide compat" choice more often. For non-versioned machine types,
again, we're OK with breaking back-compat as long as we bump a
migration version number so the user gets an error message rather
than weird behaviour.

thanks
-- PMM