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

[Jason Wang <jasowang@redhat.com>]

在 2021/7/14 下午5:14, Bin Meng 写道:
> On Wed, Jul 14, 2021 at 5:01 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>> 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 Peter. I think the above information can be put in a doc in
> docs/devel, and with some real examples to help developers on how to
> achieve backward compatibility.
>
> Regarding this series, as I mentioned in an earlier thread, I believe
> the possibility of breaking a guest is very low. Adding a back-compat
> check is not that hard either. Just not sure which factor weighs more.


Just few lines of code for the compatibility. Let's do that.

Thanks


>
> Regards,
> Bin
>