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

Commit Message

Bin Meng July 2, 2021, 9:24 a.m. UTC

From: Christina Wang <[e-mail]>

The initial value of VLAN Ether Type (VET) register is 0x8100, as per
the manual and real hardware.

While Linux e1000 driver always writes VET register to 0x8100, it is
not always the case for everyone. Drivers relying on the reset value
of VET won't be able to transmit and receive VLAN frames in QEMU.

Reported-by: Markus Carlstedt <[e-mail]>
Signed-off-by: Christina Wang <[e-mail]>
Signed-off-by: Bin Meng <[e-mail]>
---

(no changes since v1)

 hw/net/e1000.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Jason Wang July 5, 2021, 4:21 a.m. UTC | #1

在 2021/7/2 下午5:24, Bin Meng 写道:
> From: Christina Wang <[e-mail]>
>
> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
> the manual and real hardware.
>
> While Linux e1000 driver always writes VET register to 0x8100, it is
> not always the case for everyone. Drivers relying on the reset value
> of VET won't be able to transmit and receive VLAN frames in QEMU.
>
> Reported-by: Markus Carlstedt <[e-mail]>
> Signed-off-by: Christina Wang <[e-mail]>
> Signed-off-by: Bin Meng <[e-mail]>
> ---
>
> (no changes since v1)
>
>   hw/net/e1000.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 4f75b44cfc..20cbba6411 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -29,6 +29,7 @@
>   #include "hw/pci/pci.h"
>   #include "hw/qdev-properties.h"
>   #include "migration/vmstate.h"
> +#include "net/eth.h"
>   #include "net/net.h"
>   #include "net/checksum.h"
>   #include "sysemu/sysemu.h"
> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
>       [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
>                   E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
>                   E1000_MANC_RMCP_EN,
> +    [VET]     = ETH_P_VLAN,


I wonder if we need a compat flag for this, since we change the behavior.

(See e1000_properties[])

Thanks


>   };
>   
>   /* Helper function, *curr == 0 means the value is not set */

Bin Meng July 5, 2021, 5:57 a.m. UTC | #2

On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
>
>
> 在 2021/7/2 下午5:24, Bin Meng 写道:
> > From: Christina Wang <[e-mail]>
> >
> > The initial value of VLAN Ether Type (VET) register is 0x8100, as per
> > the manual and real hardware.
> >
> > While Linux e1000 driver always writes VET register to 0x8100, it is
> > not always the case for everyone. Drivers relying on the reset value
> > of VET won't be able to transmit and receive VLAN frames in QEMU.
> >
> > Reported-by: Markus Carlstedt <[e-mail]>
> > Signed-off-by: Christina Wang <[e-mail]>
> > Signed-off-by: Bin Meng <[e-mail]>
> > ---
> >
> > (no changes since v1)
> >
> >   hw/net/e1000.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> > index 4f75b44cfc..20cbba6411 100644
> > --- a/hw/net/e1000.c
> > +++ b/hw/net/e1000.c
> > @@ -29,6 +29,7 @@
> >   #include "hw/pci/pci.h"
> >   #include "hw/qdev-properties.h"
> >   #include "migration/vmstate.h"
> > +#include "net/eth.h"
> >   #include "net/net.h"
> >   #include "net/checksum.h"
> >   #include "sysemu/sysemu.h"
> > @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
> >       [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
> >                   E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
> >                   E1000_MANC_RMCP_EN,
> > +    [VET]     = ETH_P_VLAN,
>
>
> I wonder if we need a compat flag for this, since we change the behavior.
>
> (See e1000_properties[])
>

No we don't need to since it does not break migration.

Regards,
Bin

Bin Meng July 12, 2021, 11:06 p.m. UTC | #3

On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
>
> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
> >
> >
> > 在 2021/7/2 下午5:24, Bin Meng 写道:
> > > From: Christina Wang <[e-mail]>
> > >
> > > The initial value of VLAN Ether Type (VET) register is 0x8100, as per
> > > the manual and real hardware.
> > >
> > > While Linux e1000 driver always writes VET register to 0x8100, it is
> > > not always the case for everyone. Drivers relying on the reset value
> > > of VET won't be able to transmit and receive VLAN frames in QEMU.
> > >
> > > Reported-by: Markus Carlstedt <[e-mail]>
> > > Signed-off-by: Christina Wang <[e-mail]>
> > > Signed-off-by: Bin Meng <[e-mail]>
> > > ---
> > >
> > > (no changes since v1)
> > >
> > >   hw/net/e1000.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > >
> > > diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> > > index 4f75b44cfc..20cbba6411 100644
> > > --- a/hw/net/e1000.c
> > > +++ b/hw/net/e1000.c
> > > @@ -29,6 +29,7 @@
> > >   #include "hw/pci/pci.h"
> > >   #include "hw/qdev-properties.h"
> > >   #include "migration/vmstate.h"
> > > +#include "net/eth.h"
> > >   #include "net/net.h"
> > >   #include "net/checksum.h"
> > >   #include "sysemu/sysemu.h"
> > > @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
> > >       [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
> > >                   E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
> > >                   E1000_MANC_RMCP_EN,
> > > +    [VET]     = ETH_P_VLAN,
> >
> >
> > I wonder if we need a compat flag for this, since we change the behavior.
> >
> > (See e1000_properties[])
> >
>
> No we don't need to since it does not break migration.

Ping?

Jason Wang July 13, 2021, 7:03 a.m. UTC | #4

在 2021/7/13 上午7:06, Bin Meng 写道:
> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
>>>
>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
>>>> From: Christina Wang <[e-mail]>
>>>>
>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
>>>> the manual and real hardware.
>>>>
>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
>>>> not always the case for everyone. Drivers relying on the reset value
>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
>>>>
>>>> Reported-by: Markus Carlstedt <[e-mail]>
>>>> Signed-off-by: Christina Wang <[e-mail]>
>>>> Signed-off-by: Bin Meng <[e-mail]>
>>>> ---
>>>>
>>>> (no changes since v1)
>>>>
>>>>    hw/net/e1000.c | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
>>>> index 4f75b44cfc..20cbba6411 100644
>>>> --- a/hw/net/e1000.c
>>>> +++ b/hw/net/e1000.c
>>>> @@ -29,6 +29,7 @@
>>>>    #include "hw/pci/pci.h"
>>>>    #include "hw/qdev-properties.h"
>>>>    #include "migration/vmstate.h"
>>>> +#include "net/eth.h"
>>>>    #include "net/net.h"
>>>>    #include "net/checksum.h"
>>>>    #include "sysemu/sysemu.h"
>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
>>>>        [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
>>>>                    E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
>>>>                    E1000_MANC_RMCP_EN,
>>>> +    [VET]     = ETH_P_VLAN,
>>>
>>> I wonder if we need a compat flag for this, since we change the behavior.
>>>
>>> (See e1000_properties[])
>>>
>> No we don't need to since it does not break migration.
> Ping?


I admit migration "works" but it doesn't mean it's not broken. It 
changes the guest visible default value of VET register, so it may break 
things silently for the guest.

For old machine types, we should stick the value to the one without this 
fix.

Thanks


>

Bin Meng July 13, 2021, 8:36 a.m. UTC | #5

On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
>
>
> 在 2021/7/13 上午7:06, Bin Meng 写道:
> > On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
> >> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
> >>>
> >>> 在 2021/7/2 下午5:24, Bin Meng 写道:
> >>>> From: Christina Wang <[e-mail]>
> >>>>
> >>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
> >>>> the manual and real hardware.
> >>>>
> >>>> While Linux e1000 driver always writes VET register to 0x8100, it is
> >>>> not always the case for everyone. Drivers relying on the reset value
> >>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
> >>>>
> >>>> Reported-by: Markus Carlstedt <[e-mail]>
> >>>> Signed-off-by: Christina Wang <[e-mail]>
> >>>> Signed-off-by: Bin Meng <[e-mail]>
> >>>> ---
> >>>>
> >>>> (no changes since v1)
> >>>>
> >>>>    hw/net/e1000.c | 2 ++
> >>>>    1 file changed, 2 insertions(+)
> >>>>
> >>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> >>>> index 4f75b44cfc..20cbba6411 100644
> >>>> --- a/hw/net/e1000.c
> >>>> +++ b/hw/net/e1000.c
> >>>> @@ -29,6 +29,7 @@
> >>>>    #include "hw/pci/pci.h"
> >>>>    #include "hw/qdev-properties.h"
> >>>>    #include "migration/vmstate.h"
> >>>> +#include "net/eth.h"
> >>>>    #include "net/net.h"
> >>>>    #include "net/checksum.h"
> >>>>    #include "sysemu/sysemu.h"
> >>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
> >>>>        [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
> >>>>                    E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
> >>>>                    E1000_MANC_RMCP_EN,
> >>>> +    [VET]     = ETH_P_VLAN,
> >>>
> >>> I wonder if we need a compat flag for this, since we change the behavior.
> >>>
> >>> (See e1000_properties[])
> >>>
> >> No we don't need to since it does not break migration.
> > Ping?
>
>
> I admit migration "works" but it doesn't mean it's not broken. It
> changes the guest visible default value of VET register, so it may break
> things silently for the guest.
>
> For old machine types, we should stick the value to the one without this
> fix.

Could you please propose a solution on how to handle such a scenario
in a generic way in QEMU? (+Peter)

The POR reset value is wrong in QEMU and has carried forward the wrong
value for years, and correcting it to its right value needs to do
what?

Regards,
Bin

Jason Wang July 13, 2021, 9:02 a.m. UTC | #6

在 2021/7/13 下午4:36, Bin Meng 写道:
> On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
>>
>> 在 2021/7/13 上午7:06, Bin Meng 写道:
>>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
>>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
>>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
>>>>>> From: Christina Wang <[e-mail]>
>>>>>>
>>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
>>>>>> the manual and real hardware.
>>>>>>
>>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
>>>>>> not always the case for everyone. Drivers relying on the reset value
>>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
>>>>>>
>>>>>> Reported-by: Markus Carlstedt <[e-mail]>
>>>>>> Signed-off-by: Christina Wang <[e-mail]>
>>>>>> Signed-off-by: Bin Meng <[e-mail]>
>>>>>> ---
>>>>>>
>>>>>> (no changes since v1)
>>>>>>
>>>>>>     hw/net/e1000.c | 2 ++
>>>>>>     1 file changed, 2 insertions(+)
>>>>>>
>>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
>>>>>> index 4f75b44cfc..20cbba6411 100644
>>>>>> --- a/hw/net/e1000.c
>>>>>> +++ b/hw/net/e1000.c
>>>>>> @@ -29,6 +29,7 @@
>>>>>>     #include "hw/pci/pci.h"
>>>>>>     #include "hw/qdev-properties.h"
>>>>>>     #include "migration/vmstate.h"
>>>>>> +#include "net/eth.h"
>>>>>>     #include "net/net.h"
>>>>>>     #include "net/checksum.h"
>>>>>>     #include "sysemu/sysemu.h"
>>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
>>>>>>         [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
>>>>>>                     E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
>>>>>>                     E1000_MANC_RMCP_EN,
>>>>>> +    [VET]     = ETH_P_VLAN,
>>>>> I wonder if we need a compat flag for this, since we change the behavior.
>>>>>
>>>>> (See e1000_properties[])
>>>>>
>>>> No we don't need to since it does not break migration.
>>> Ping?
>>
>> I admit migration "works" but it doesn't mean it's not broken. It
>> changes the guest visible default value of VET register, so it may break
>> things silently for the guest.
>>
>> For old machine types, we should stick the value to the one without this
>> fix.
> Could you please propose a solution on how to handle such a scenario
> in a generic way in QEMU? (+Peter)


Well, I think I've suggested you to have a look at how things is done in 
for handling such compatibility in e1000_properties.


>
> The POR reset value is wrong in QEMU and has carried forward the wrong
> value for years, and correcting it to its right value needs to do
> what?


We should stick to the wrong behavior for old machine types.

That's all.


>
> Regards,
> Bin
>

Bin Meng July 13, 2021, 9:11 a.m. UTC | #7

On Tue, Jul 13, 2021 at 5:02 PM Jason Wang <[e-mail]> wrote:
>
>
> 在 2021/7/13 下午4:36, Bin Meng 写道:
> > On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
> >>
> >> 在 2021/7/13 上午7:06, Bin Meng 写道:
> >>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
> >>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
> >>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
> >>>>>> From: Christina Wang <[e-mail]>
> >>>>>>
> >>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
> >>>>>> the manual and real hardware.
> >>>>>>
> >>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
> >>>>>> not always the case for everyone. Drivers relying on the reset value
> >>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
> >>>>>>
> >>>>>> Reported-by: Markus Carlstedt <[e-mail]>
> >>>>>> Signed-off-by: Christina Wang <[e-mail]>
> >>>>>> Signed-off-by: Bin Meng <[e-mail]>
> >>>>>> ---
> >>>>>>
> >>>>>> (no changes since v1)
> >>>>>>
> >>>>>>     hw/net/e1000.c | 2 ++
> >>>>>>     1 file changed, 2 insertions(+)
> >>>>>>
> >>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> >>>>>> index 4f75b44cfc..20cbba6411 100644
> >>>>>> --- a/hw/net/e1000.c
> >>>>>> +++ b/hw/net/e1000.c
> >>>>>> @@ -29,6 +29,7 @@
> >>>>>>     #include "hw/pci/pci.h"
> >>>>>>     #include "hw/qdev-properties.h"
> >>>>>>     #include "migration/vmstate.h"
> >>>>>> +#include "net/eth.h"
> >>>>>>     #include "net/net.h"
> >>>>>>     #include "net/checksum.h"
> >>>>>>     #include "sysemu/sysemu.h"
> >>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
> >>>>>>         [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
> >>>>>>                     E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
> >>>>>>                     E1000_MANC_RMCP_EN,
> >>>>>> +    [VET]     = ETH_P_VLAN,
> >>>>> I wonder if we need a compat flag for this, since we change the behavior.
> >>>>>
> >>>>> (See e1000_properties[])
> >>>>>
> >>>> No we don't need to since it does not break migration.
> >>> Ping?
> >>
> >> I admit migration "works" but it doesn't mean it's not broken. It
> >> changes the guest visible default value of VET register, so it may break
> >> things silently for the guest.
> >>
> >> For old machine types, we should stick the value to the one without this
> >> fix.
> > Could you please propose a solution on how to handle such a scenario
> > in a generic way in QEMU? (+Peter)
>
>
> Well, I think I've suggested you to have a look at how things is done in
> for handling such compatibility in e1000_properties.
>
>
> >
> > The POR reset value is wrong in QEMU and has carried forward the wrong
> > value for years, and correcting it to its right value needs to do
> > what?
>
>
> We should stick to the wrong behavior for old machine types.
>
> That's all.

So that means the following SD patch is also wrong (+Philippe) which
changes the default value of capability register.
http://patchwork.ozlabs.org/project/qemu-devel/patch/[e-mail]/

Can we get some agreement among maintainers?

Regards,
Bin

Jason Wang July 14, 2021, 3:10 a.m. UTC | #8

在 2021/7/13 下午5:11, Bin Meng 写道:
> On Tue, Jul 13, 2021 at 5:02 PM Jason Wang <[e-mail]> wrote:
>>
>> 在 2021/7/13 下午4:36, Bin Meng 写道:
>>> On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
>>>> 在 2021/7/13 上午7:06, Bin Meng 写道:
>>>>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
>>>>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
>>>>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
>>>>>>>> From: Christina Wang <[e-mail]>
>>>>>>>>
>>>>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
>>>>>>>> the manual and real hardware.
>>>>>>>>
>>>>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
>>>>>>>> not always the case for everyone. Drivers relying on the reset value
>>>>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
>>>>>>>>
>>>>>>>> Reported-by: Markus Carlstedt <[e-mail]>
>>>>>>>> Signed-off-by: Christina Wang <[e-mail]>
>>>>>>>> Signed-off-by: Bin Meng <[e-mail]>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> (no changes since v1)
>>>>>>>>
>>>>>>>>      hw/net/e1000.c | 2 ++
>>>>>>>>      1 file changed, 2 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
>>>>>>>> index 4f75b44cfc..20cbba6411 100644
>>>>>>>> --- a/hw/net/e1000.c
>>>>>>>> +++ b/hw/net/e1000.c
>>>>>>>> @@ -29,6 +29,7 @@
>>>>>>>>      #include "hw/pci/pci.h"
>>>>>>>>      #include "hw/qdev-properties.h"
>>>>>>>>      #include "migration/vmstate.h"
>>>>>>>> +#include "net/eth.h"
>>>>>>>>      #include "net/net.h"
>>>>>>>>      #include "net/checksum.h"
>>>>>>>>      #include "sysemu/sysemu.h"
>>>>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
>>>>>>>>          [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
>>>>>>>>                      E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
>>>>>>>>                      E1000_MANC_RMCP_EN,
>>>>>>>> +    [VET]     = ETH_P_VLAN,
>>>>>>> I wonder if we need a compat flag for this, since we change the behavior.
>>>>>>>
>>>>>>> (See e1000_properties[])
>>>>>>>
>>>>>> No we don't need to since it does not break migration.
>>>>> Ping?
>>>> I admit migration "works" but it doesn't mean it's not broken. It
>>>> changes the guest visible default value of VET register, so it may break
>>>> things silently for the guest.
>>>>
>>>> For old machine types, we should stick the value to the one without this
>>>> fix.
>>> Could you please propose a solution on how to handle such a scenario
>>> in a generic way in QEMU? (+Peter)
>>
>> Well, I think I've suggested you to have a look at how things is done in
>> for handling such compatibility in e1000_properties.
>>
>>
>>> The POR reset value is wrong in QEMU and has carried forward the wrong
>>> value for years, and correcting it to its right value needs to do
>>> what?
>>
>> We should stick to the wrong behavior for old machine types.
>>
>> That's all.
> So that means the following SD patch is also wrong (+Philippe) which
> changes the default value of capability register.
> http://patchwork.ozlabs.org/project/qemu-devel/patch/[e-mail]/


It should compat capareg for the old value for old machine types.


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

Thanks


>
> Regards,
> Bin
>

Bin Meng July 14, 2021, 3:42 a.m. UTC | #9

On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> wrote:
>
>
> 在 2021/7/13 下午5:11, Bin Meng 写道:
> > On Tue, Jul 13, 2021 at 5:02 PM Jason Wang <[e-mail]> wrote:
> >>
> >> 在 2021/7/13 下午4:36, Bin Meng 写道:
> >>> On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
> >>>> 在 2021/7/13 上午7:06, Bin Meng 写道:
> >>>>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
> >>>>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
> >>>>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
> >>>>>>>> From: Christina Wang <[e-mail]>
> >>>>>>>>
> >>>>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
> >>>>>>>> the manual and real hardware.
> >>>>>>>>
> >>>>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
> >>>>>>>> not always the case for everyone. Drivers relying on the reset value
> >>>>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
> >>>>>>>>
> >>>>>>>> Reported-by: Markus Carlstedt <[e-mail]>
> >>>>>>>> Signed-off-by: Christina Wang <[e-mail]>
> >>>>>>>> Signed-off-by: Bin Meng <[e-mail]>
> >>>>>>>> ---
> >>>>>>>>
> >>>>>>>> (no changes since v1)
> >>>>>>>>
> >>>>>>>>      hw/net/e1000.c | 2 ++
> >>>>>>>>      1 file changed, 2 insertions(+)
> >>>>>>>>
> >>>>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> >>>>>>>> index 4f75b44cfc..20cbba6411 100644
> >>>>>>>> --- a/hw/net/e1000.c
> >>>>>>>> +++ b/hw/net/e1000.c
> >>>>>>>> @@ -29,6 +29,7 @@
> >>>>>>>>      #include "hw/pci/pci.h"
> >>>>>>>>      #include "hw/qdev-properties.h"
> >>>>>>>>      #include "migration/vmstate.h"
> >>>>>>>> +#include "net/eth.h"
> >>>>>>>>      #include "net/net.h"
> >>>>>>>>      #include "net/checksum.h"
> >>>>>>>>      #include "sysemu/sysemu.h"
> >>>>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
> >>>>>>>>          [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
> >>>>>>>>                      E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
> >>>>>>>>                      E1000_MANC_RMCP_EN,
> >>>>>>>> +    [VET]     = ETH_P_VLAN,
> >>>>>>> I wonder if we need a compat flag for this, since we change the behavior.
> >>>>>>>
> >>>>>>> (See e1000_properties[])
> >>>>>>>
> >>>>>> No we don't need to since it does not break migration.
> >>>>> Ping?
> >>>> I admit migration "works" but it doesn't mean it's not broken. It
> >>>> changes the guest visible default value of VET register, so it may break
> >>>> things silently for the guest.
> >>>>
> >>>> For old machine types, we should stick the value to the one without this
> >>>> fix.
> >>> Could you please propose a solution on how to handle such a scenario
> >>> in a generic way in QEMU? (+Peter)
> >>
> >> Well, I think I've suggested you to have a look at how things is done in
> >> for handling such compatibility in e1000_properties.
> >>
> >>
> >>> The POR reset value is wrong in QEMU and has carried forward the wrong
> >>> value for years, and correcting it to its right value needs to do
> >>> what?
> >>
> >> We should stick to the wrong behavior for old machine types.
> >>
> >> That's all.
> > So that means the following SD patch is also wrong (+Philippe) which
> > changes the default value of capability register.
> > http://patchwork.ozlabs.org/project/qemu-devel/patch/[e-mail]/
>
>
> It should compat capareg for the old value for old machine types.

Yeah, it's already a property for the SD controller model but someone
views it as a bug because the model implements 64-bit but not
reporting it in the capability register.

>
>
> >
> > 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")

Regards,
Bin

Jason Wang July 14, 2021, 4:53 a.m. UTC | #10

在 2021/7/14 上午11:42, Bin Meng 写道:
> On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> wrote:
>>
>> 在 2021/7/13 下午5:11, Bin Meng 写道:
>>> On Tue, Jul 13, 2021 at 5:02 PM Jason Wang <[e-mail]> wrote:
>>>> 在 2021/7/13 下午4:36, Bin Meng 写道:
>>>>> On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
>>>>>> 在 2021/7/13 上午7:06, Bin Meng 写道:
>>>>>>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
>>>>>>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
>>>>>>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
>>>>>>>>>> From: Christina Wang <[e-mail]>
>>>>>>>>>>
>>>>>>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
>>>>>>>>>> the manual and real hardware.
>>>>>>>>>>
>>>>>>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
>>>>>>>>>> not always the case for everyone. Drivers relying on the reset value
>>>>>>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
>>>>>>>>>>
>>>>>>>>>> Reported-by: Markus Carlstedt <[e-mail]>
>>>>>>>>>> Signed-off-by: Christina Wang <[e-mail]>
>>>>>>>>>> Signed-off-by: Bin Meng <[e-mail]>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> (no changes since v1)
>>>>>>>>>>
>>>>>>>>>>       hw/net/e1000.c | 2 ++
>>>>>>>>>>       1 file changed, 2 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
>>>>>>>>>> index 4f75b44cfc..20cbba6411 100644
>>>>>>>>>> --- a/hw/net/e1000.c
>>>>>>>>>> +++ b/hw/net/e1000.c
>>>>>>>>>> @@ -29,6 +29,7 @@
>>>>>>>>>>       #include "hw/pci/pci.h"
>>>>>>>>>>       #include "hw/qdev-properties.h"
>>>>>>>>>>       #include "migration/vmstate.h"
>>>>>>>>>> +#include "net/eth.h"
>>>>>>>>>>       #include "net/net.h"
>>>>>>>>>>       #include "net/checksum.h"
>>>>>>>>>>       #include "sysemu/sysemu.h"
>>>>>>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
>>>>>>>>>>           [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
>>>>>>>>>>                       E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
>>>>>>>>>>                       E1000_MANC_RMCP_EN,
>>>>>>>>>> +    [VET]     = ETH_P_VLAN,
>>>>>>>>> I wonder if we need a compat flag for this, since we change the behavior.
>>>>>>>>>
>>>>>>>>> (See e1000_properties[])
>>>>>>>>>
>>>>>>>> No we don't need to since it does not break migration.
>>>>>>> Ping?
>>>>>> I admit migration "works" but it doesn't mean it's not broken. It
>>>>>> changes the guest visible default value of VET register, so it may break
>>>>>> things silently for the guest.
>>>>>>
>>>>>> For old machine types, we should stick the value to the one without this
>>>>>> fix.
>>>>> Could you please propose a solution on how to handle such a scenario
>>>>> in a generic way in QEMU? (+Peter)
>>>> Well, I think I've suggested you to have a look at how things is done in
>>>> for handling such compatibility in e1000_properties.
>>>>
>>>>
>>>>> The POR reset value is wrong in QEMU and has carried forward the wrong
>>>>> value for years, and correcting it to its right value needs to do
>>>>> what?
>>>> We should stick to the wrong behavior for old machine types.
>>>>
>>>> That's all.
>>> So that means the following SD patch is also wrong (+Philippe) which
>>> changes the default value of capability register.
>>> http://patchwork.ozlabs.org/project/qemu-devel/patch/[e-mail]/
>>
>> It should compat capareg for the old value for old machine types.
> Yeah, it's already a property for the SD controller model but someone
> views it as a bug because the model implements 64-bit but not
> reporting it in the capability register.
>
>>
>>> 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.


That's the price for the stable ABI. See one of my recent fix - 
d83f46d189 virtio-pci: compat page aligned ATS. It keeps the "buggy" 
behavior to unbreak the migration.


>
> 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")


I guess it's simply because fsl_etsec is not used in any 
distributions/production environments or the maintainer may just not 
notice things like this.

But for e1000(e), we should stick to a stable ABI for consistency. 
Otherwise it would be very tricky to fix them after we saw real issues. 
We had learnt a lot during the past decade.

Thanks


>
> Regards,
> Bin
>

Bin Meng July 14, 2021, 6:04 a.m. UTC | #11

On Wed, Jul 14, 2021 at 12:53 PM Jason Wang <[e-mail]> wrote:
>
>
> 在 2021/7/14 上午11:42, Bin Meng 写道:
> > On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> wrote:
> >>
> >> 在 2021/7/13 下午5:11, Bin Meng 写道:
> >>> On Tue, Jul 13, 2021 at 5:02 PM Jason Wang <[e-mail]> wrote:
> >>>> 在 2021/7/13 下午4:36, Bin Meng 写道:
> >>>>> On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
> >>>>>> 在 2021/7/13 上午7:06, Bin Meng 写道:
> >>>>>>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
> >>>>>>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
> >>>>>>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
> >>>>>>>>>> From: Christina Wang <[e-mail]>
> >>>>>>>>>>
> >>>>>>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
> >>>>>>>>>> the manual and real hardware.
> >>>>>>>>>>
> >>>>>>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
> >>>>>>>>>> not always the case for everyone. Drivers relying on the reset value
> >>>>>>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
> >>>>>>>>>>
> >>>>>>>>>> Reported-by: Markus Carlstedt <[e-mail]>
> >>>>>>>>>> Signed-off-by: Christina Wang <[e-mail]>
> >>>>>>>>>> Signed-off-by: Bin Meng <[e-mail]>
> >>>>>>>>>> ---
> >>>>>>>>>>
> >>>>>>>>>> (no changes since v1)
> >>>>>>>>>>
> >>>>>>>>>>       hw/net/e1000.c | 2 ++
> >>>>>>>>>>       1 file changed, 2 insertions(+)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> >>>>>>>>>> index 4f75b44cfc..20cbba6411 100644
> >>>>>>>>>> --- a/hw/net/e1000.c
> >>>>>>>>>> +++ b/hw/net/e1000.c
> >>>>>>>>>> @@ -29,6 +29,7 @@
> >>>>>>>>>>       #include "hw/pci/pci.h"
> >>>>>>>>>>       #include "hw/qdev-properties.h"
> >>>>>>>>>>       #include "migration/vmstate.h"
> >>>>>>>>>> +#include "net/eth.h"
> >>>>>>>>>>       #include "net/net.h"
> >>>>>>>>>>       #include "net/checksum.h"
> >>>>>>>>>>       #include "sysemu/sysemu.h"
> >>>>>>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
> >>>>>>>>>>           [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
> >>>>>>>>>>                       E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
> >>>>>>>>>>                       E1000_MANC_RMCP_EN,
> >>>>>>>>>> +    [VET]     = ETH_P_VLAN,
> >>>>>>>>> I wonder if we need a compat flag for this, since we change the behavior.
> >>>>>>>>>
> >>>>>>>>> (See e1000_properties[])
> >>>>>>>>>
> >>>>>>>> No we don't need to since it does not break migration.
> >>>>>>> Ping?
> >>>>>> I admit migration "works" but it doesn't mean it's not broken. It
> >>>>>> changes the guest visible default value of VET register, so it may break
> >>>>>> things silently for the guest.
> >>>>>>
> >>>>>> For old machine types, we should stick the value to the one without this
> >>>>>> fix.
> >>>>> Could you please propose a solution on how to handle such a scenario
> >>>>> in a generic way in QEMU? (+Peter)
> >>>> Well, I think I've suggested you to have a look at how things is done in
> >>>> for handling such compatibility in e1000_properties.
> >>>>
> >>>>
> >>>>> The POR reset value is wrong in QEMU and has carried forward the wrong
> >>>>> value for years, and correcting it to its right value needs to do
> >>>>> what?
> >>>> We should stick to the wrong behavior for old machine types.
> >>>>
> >>>> That's all.
> >>> So that means the following SD patch is also wrong (+Philippe) which
> >>> changes the default value of capability register.
> >>> http://patchwork.ozlabs.org/project/qemu-devel/patch/[e-mail]/
> >>
> >> It should compat capareg for the old value for old machine types.
> > Yeah, it's already a property for the SD controller model but someone
> > views it as a bug because the model implements 64-bit but not
> > reporting it in the capability register.
> >
> >>
> >>> 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.
>
>
> That's the price for the stable ABI. See one of my recent fix -
> d83f46d189 virtio-pci: compat page aligned ATS. It keeps the "buggy"
> behavior to unbreak the migration.
>

But this series does not break the migration, as we discussed in the
previous thread.

> >
> > 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")
>
>
> I guess it's simply because fsl_etsec is not used in any
> distributions/production environments or the maintainer may just not
> notice things like this.
>
> But for e1000(e), we should stick to a stable ABI for consistency.
> Otherwise it would be very tricky to fix them after we saw real issues.
> We had learnt a lot during the past decade.
>

Okay, do we have such a kind of widely used device model list? And we
should document such a process that we should keep compatibility on
these devices as well.

Regarding this VET register, do you know what guest relies on the POR
value which is zero? Zero is not a valid ethernet VLAN type. I don't
think changing this will break any guests. The commit message says
Linux e1000(e) driver just rewrites this register by itself. Given
that's probably the most commonly used OS, it's not strange this bug
gets unnoticed for years.

Regards,
Bin

Jason Wang July 14, 2021, 8:40 a.m. UTC | #12

在 2021/7/14 下午2:04, Bin Meng 写道:
> On Wed, Jul 14, 2021 at 12:53 PM Jason Wang <[e-mail]> wrote:
>>
>> 在 2021/7/14 上午11:42, Bin Meng 写道:
>>> On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> wrote:
>>>> 在 2021/7/13 下午5:11, Bin Meng 写道:
>>>>> On Tue, Jul 13, 2021 at 5:02 PM Jason Wang <[e-mail]> wrote:
>>>>>> 在 2021/7/13 下午4:36, Bin Meng 写道:
>>>>>>> On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
>>>>>>>> 在 2021/7/13 上午7:06, Bin Meng 写道:
>>>>>>>>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
>>>>>>>>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
>>>>>>>>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
>>>>>>>>>>>> From: Christina Wang <[e-mail]>
>>>>>>>>>>>>
>>>>>>>>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
>>>>>>>>>>>> the manual and real hardware.
>>>>>>>>>>>>
>>>>>>>>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
>>>>>>>>>>>> not always the case for everyone. Drivers relying on the reset value
>>>>>>>>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
>>>>>>>>>>>>
>>>>>>>>>>>> Reported-by: Markus Carlstedt <[e-mail]>
>>>>>>>>>>>> Signed-off-by: Christina Wang <[e-mail]>
>>>>>>>>>>>> Signed-off-by: Bin Meng <[e-mail]>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> (no changes since v1)
>>>>>>>>>>>>
>>>>>>>>>>>>        hw/net/e1000.c | 2 ++
>>>>>>>>>>>>        1 file changed, 2 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
>>>>>>>>>>>> index 4f75b44cfc..20cbba6411 100644
>>>>>>>>>>>> --- a/hw/net/e1000.c
>>>>>>>>>>>> +++ b/hw/net/e1000.c
>>>>>>>>>>>> @@ -29,6 +29,7 @@
>>>>>>>>>>>>        #include "hw/pci/pci.h"
>>>>>>>>>>>>        #include "hw/qdev-properties.h"
>>>>>>>>>>>>        #include "migration/vmstate.h"
>>>>>>>>>>>> +#include "net/eth.h"
>>>>>>>>>>>>        #include "net/net.h"
>>>>>>>>>>>>        #include "net/checksum.h"
>>>>>>>>>>>>        #include "sysemu/sysemu.h"
>>>>>>>>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
>>>>>>>>>>>>            [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
>>>>>>>>>>>>                        E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
>>>>>>>>>>>>                        E1000_MANC_RMCP_EN,
>>>>>>>>>>>> +    [VET]     = ETH_P_VLAN,
>>>>>>>>>>> I wonder if we need a compat flag for this, since we change the behavior.
>>>>>>>>>>>
>>>>>>>>>>> (See e1000_properties[])
>>>>>>>>>>>
>>>>>>>>>> No we don't need to since it does not break migration.
>>>>>>>>> Ping?
>>>>>>>> I admit migration "works" but it doesn't mean it's not broken. It
>>>>>>>> changes the guest visible default value of VET register, so it may break
>>>>>>>> things silently for the guest.
>>>>>>>>
>>>>>>>> For old machine types, we should stick the value to the one without this
>>>>>>>> fix.
>>>>>>> Could you please propose a solution on how to handle such a scenario
>>>>>>> in a generic way in QEMU? (+Peter)
>>>>>> Well, I think I've suggested you to have a look at how things is done in
>>>>>> for handling such compatibility in e1000_properties.
>>>>>>
>>>>>>
>>>>>>> The POR reset value is wrong in QEMU and has carried forward the wrong
>>>>>>> value for years, and correcting it to its right value needs to do
>>>>>>> what?
>>>>>> We should stick to the wrong behavior for old machine types.
>>>>>>
>>>>>> That's all.
>>>>> So that means the following SD patch is also wrong (+Philippe) which
>>>>> changes the default value of capability register.
>>>>> http://patchwork.ozlabs.org/project/qemu-devel/patch/[e-mail]/
>>>> It should compat capareg for the old value for old machine types.
>>> Yeah, it's already a property for the SD controller model but someone
>>> views it as a bug because the model implements 64-bit but not
>>> reporting it in the capability register.
>>>
>>>>> 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.
>>
>> That's the price for the stable ABI. See one of my recent fix -
>> d83f46d189 virtio-pci: compat page aligned ATS. It keeps the "buggy"
>> behavior to unbreak the migration.
>>
> But this series does not break the migration, as we discussed in the
> previous thread.


It actually did,

(qemu) qemu-kvm: get_pci_config_device: Bad config data: i=0x104 read:
     0 device: 20 cmask: ff wmask: 0 w1cmask:0

Since the register is RO.


>
>>> 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")
>>
>> I guess it's simply because fsl_etsec is not used in any
>> distributions/production environments or the maintainer may just not
>> notice things like this.
>>
>> But for e1000(e), we should stick to a stable ABI for consistency.
>> Otherwise it would be very tricky to fix them after we saw real issues.
>> We had learnt a lot during the past decade.
>>
> Okay, do we have such a kind of widely used device model list? And we
> should document such a process that we should keep compatibility on
> these devices as well.


I can only say for networking devices:

- e1000(e)
- rtl8139
- virtio-net


>
> Regarding this VET register, do you know what guest relies on the POR
> value which is zero?


I don't know.


> Zero is not a valid ethernet VLAN type. I don't
> think changing this will break any guests.


You might be right here, but it would be late if we find it breaks any one.

If it's not a lot of work, I tend to bother with compat stuffs for this.

Thanks


> The commit message says
> Linux e1000(e) driver just rewrites this register by itself. Given
> that's probably the most commonly used OS, it's not strange this bug
> gets unnoticed for years.
>
> Regards,
> Bin
>

Peter Maydell July 14, 2021, 9 a.m. UTC | #13

On Wed, 14 Jul 2021 at 04:42, Bin Meng <[e-mail]> wrote:
>
> On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> 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

Bin Meng July 14, 2021, 9:05 a.m. UTC | #14

On Wed, Jul 14, 2021 at 4:40 PM Jason Wang <[e-mail]> wrote:
>
>
> 在 2021/7/14 下午2:04, Bin Meng 写道:
> > On Wed, Jul 14, 2021 at 12:53 PM Jason Wang <[e-mail]> wrote:
> >>
> >> 在 2021/7/14 上午11:42, Bin Meng 写道:
> >>> On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> wrote:
> >>>> 在 2021/7/13 下午5:11, Bin Meng 写道:
> >>>>> On Tue, Jul 13, 2021 at 5:02 PM Jason Wang <[e-mail]> wrote:
> >>>>>> 在 2021/7/13 下午4:36, Bin Meng 写道:
> >>>>>>> On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
> >>>>>>>> 在 2021/7/13 上午7:06, Bin Meng 写道:
> >>>>>>>>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
> >>>>>>>>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
> >>>>>>>>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
> >>>>>>>>>>>> From: Christina Wang <[e-mail]>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
> >>>>>>>>>>>> the manual and real hardware.
> >>>>>>>>>>>>
> >>>>>>>>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
> >>>>>>>>>>>> not always the case for everyone. Drivers relying on the reset value
> >>>>>>>>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Reported-by: Markus Carlstedt <[e-mail]>
> >>>>>>>>>>>> Signed-off-by: Christina Wang <[e-mail]>
> >>>>>>>>>>>> Signed-off-by: Bin Meng <[e-mail]>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> (no changes since v1)
> >>>>>>>>>>>>
> >>>>>>>>>>>>        hw/net/e1000.c | 2 ++
> >>>>>>>>>>>>        1 file changed, 2 insertions(+)
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> >>>>>>>>>>>> index 4f75b44cfc..20cbba6411 100644
> >>>>>>>>>>>> --- a/hw/net/e1000.c
> >>>>>>>>>>>> +++ b/hw/net/e1000.c
> >>>>>>>>>>>> @@ -29,6 +29,7 @@
> >>>>>>>>>>>>        #include "hw/pci/pci.h"
> >>>>>>>>>>>>        #include "hw/qdev-properties.h"
> >>>>>>>>>>>>        #include "migration/vmstate.h"
> >>>>>>>>>>>> +#include "net/eth.h"
> >>>>>>>>>>>>        #include "net/net.h"
> >>>>>>>>>>>>        #include "net/checksum.h"
> >>>>>>>>>>>>        #include "sysemu/sysemu.h"
> >>>>>>>>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
> >>>>>>>>>>>>            [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
> >>>>>>>>>>>>                        E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
> >>>>>>>>>>>>                        E1000_MANC_RMCP_EN,
> >>>>>>>>>>>> +    [VET]     = ETH_P_VLAN,
> >>>>>>>>>>> I wonder if we need a compat flag for this, since we change the behavior.
> >>>>>>>>>>>
> >>>>>>>>>>> (See e1000_properties[])
> >>>>>>>>>>>
> >>>>>>>>>> No we don't need to since it does not break migration.
> >>>>>>>>> Ping?
> >>>>>>>> I admit migration "works" but it doesn't mean it's not broken. It
> >>>>>>>> changes the guest visible default value of VET register, so it may break
> >>>>>>>> things silently for the guest.
> >>>>>>>>
> >>>>>>>> For old machine types, we should stick the value to the one without this
> >>>>>>>> fix.
> >>>>>>> Could you please propose a solution on how to handle such a scenario
> >>>>>>> in a generic way in QEMU? (+Peter)
> >>>>>> Well, I think I've suggested you to have a look at how things is done in
> >>>>>> for handling such compatibility in e1000_properties.
> >>>>>>
> >>>>>>
> >>>>>>> The POR reset value is wrong in QEMU and has carried forward the wrong
> >>>>>>> value for years, and correcting it to its right value needs to do
> >>>>>>> what?
> >>>>>> We should stick to the wrong behavior for old machine types.
> >>>>>>
> >>>>>> That's all.
> >>>>> So that means the following SD patch is also wrong (+Philippe) which
> >>>>> changes the default value of capability register.
> >>>>> http://patchwork.ozlabs.org/project/qemu-devel/patch/[e-mail]/
> >>>> It should compat capareg for the old value for old machine types.
> >>> Yeah, it's already a property for the SD controller model but someone
> >>> views it as a bug because the model implements 64-bit but not
> >>> reporting it in the capability register.
> >>>
> >>>>> 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.
> >>
> >> That's the price for the stable ABI. See one of my recent fix -
> >> d83f46d189 virtio-pci: compat page aligned ATS. It keeps the "buggy"
> >> behavior to unbreak the migration.
> >>
> > But this series does not break the migration, as we discussed in the
> > previous thread.
>
>
> It actually did,
>
> (qemu) qemu-kvm: get_pci_config_device: Bad config data: i=0x104 read:
>      0 device: 20 cmask: ff wmask: 0 w1cmask:0
>
> Since the register is RO.

Did you mean the VET register is read-only? I don't understand this as
the manual says it's RW and Linux driver programs it to 0x8100.

>
>
> >
> >>> 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")
> >>
> >> I guess it's simply because fsl_etsec is not used in any
> >> distributions/production environments or the maintainer may just not
> >> notice things like this.
> >>
> >> But for e1000(e), we should stick to a stable ABI for consistency.
> >> Otherwise it would be very tricky to fix them after we saw real issues.
> >> We had learnt a lot during the past decade.
> >>
> > Okay, do we have such a kind of widely used device model list? And we
> > should document such a process that we should keep compatibility on
> > these devices as well.
>
>
> I can only say for networking devices:
>
> - e1000(e)
> - rtl8139
> - virtio-net
>

Please, at least have these documented as a development process.

> >
> > Regarding this VET register, do you know what guest relies on the POR
> > value which is zero?
>
>
> I don't know.
>
>
> > Zero is not a valid ethernet VLAN type. I don't
> > think changing this will break any guests.
>
>
> You might be right here, but it would be late if we find it breaks any one.
>
> If it's not a lot of work, I tend to bother with compat stuffs for this.
>

Regards,
Bin

Bin Meng July 14, 2021, 9:14 a.m. UTC | #15

On Wed, Jul 14, 2021 at 5:01 PM Peter Maydell <[e-mail]> wrote:
>
> On Wed, 14 Jul 2021 at 04:42, Bin Meng <[e-mail]> wrote:
> >
> > On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> 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.

Regards,
Bin

Jason Wang July 14, 2021, 9:17 a.m. UTC | #16

在 2021/7/14 下午5:05, Bin Meng 写道:
> On Wed, Jul 14, 2021 at 4:40 PM Jason Wang <[e-mail]> wrote:
>>
>> 在 2021/7/14 下午2:04, Bin Meng 写道:
>>> On Wed, Jul 14, 2021 at 12:53 PM Jason Wang <[e-mail]> wrote:
>>>> 在 2021/7/14 上午11:42, Bin Meng 写道:
>>>>> On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> wrote:
>>>>>> 在 2021/7/13 下午5:11, Bin Meng 写道:
>>>>>>> On Tue, Jul 13, 2021 at 5:02 PM Jason Wang <[e-mail]> wrote:
>>>>>>>> 在 2021/7/13 下午4:36, Bin Meng 写道:
>>>>>>>>> On Tue, Jul 13, 2021 at 3:03 PM Jason Wang <[e-mail]> wrote:
>>>>>>>>>> 在 2021/7/13 上午7:06, Bin Meng 写道:
>>>>>>>>>>> On Mon, Jul 5, 2021 at 1:57 PM Bin Meng <[e-mail]> wrote:
>>>>>>>>>>>> On Mon, Jul 5, 2021 at 12:21 PM Jason Wang <[e-mail]> wrote:
>>>>>>>>>>>>> 在 2021/7/2 下午5:24, Bin Meng 写道:
>>>>>>>>>>>>>> From: Christina Wang <[e-mail]>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The initial value of VLAN Ether Type (VET) register is 0x8100, as per
>>>>>>>>>>>>>> the manual and real hardware.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> While Linux e1000 driver always writes VET register to 0x8100, it is
>>>>>>>>>>>>>> not always the case for everyone. Drivers relying on the reset value
>>>>>>>>>>>>>> of VET won't be able to transmit and receive VLAN frames in QEMU.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Reported-by: Markus Carlstedt <[e-mail]>
>>>>>>>>>>>>>> Signed-off-by: Christina Wang <[e-mail]>
>>>>>>>>>>>>>> Signed-off-by: Bin Meng <[e-mail]>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (no changes since v1)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         hw/net/e1000.c | 2 ++
>>>>>>>>>>>>>>         1 file changed, 2 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
>>>>>>>>>>>>>> index 4f75b44cfc..20cbba6411 100644
>>>>>>>>>>>>>> --- a/hw/net/e1000.c
>>>>>>>>>>>>>> +++ b/hw/net/e1000.c
>>>>>>>>>>>>>> @@ -29,6 +29,7 @@
>>>>>>>>>>>>>>         #include "hw/pci/pci.h"
>>>>>>>>>>>>>>         #include "hw/qdev-properties.h"
>>>>>>>>>>>>>>         #include "migration/vmstate.h"
>>>>>>>>>>>>>> +#include "net/eth.h"
>>>>>>>>>>>>>>         #include "net/net.h"
>>>>>>>>>>>>>>         #include "net/checksum.h"
>>>>>>>>>>>>>>         #include "sysemu/sysemu.h"
>>>>>>>>>>>>>> @@ -254,6 +255,7 @@ static const uint32_t mac_reg_init[] = {
>>>>>>>>>>>>>>             [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
>>>>>>>>>>>>>>                         E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
>>>>>>>>>>>>>>                         E1000_MANC_RMCP_EN,
>>>>>>>>>>>>>> +    [VET]     = ETH_P_VLAN,
>>>>>>>>>>>>> I wonder if we need a compat flag for this, since we change the behavior.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (See e1000_properties[])
>>>>>>>>>>>>>
>>>>>>>>>>>> No we don't need to since it does not break migration.
>>>>>>>>>>> Ping?
>>>>>>>>>> I admit migration "works" but it doesn't mean it's not broken. It
>>>>>>>>>> changes the guest visible default value of VET register, so it may break
>>>>>>>>>> things silently for the guest.
>>>>>>>>>>
>>>>>>>>>> For old machine types, we should stick the value to the one without this
>>>>>>>>>> fix.
>>>>>>>>> Could you please propose a solution on how to handle such a scenario
>>>>>>>>> in a generic way in QEMU? (+Peter)
>>>>>>>> Well, I think I've suggested you to have a look at how things is done in
>>>>>>>> for handling such compatibility in e1000_properties.
>>>>>>>>
>>>>>>>>
>>>>>>>>> The POR reset value is wrong in QEMU and has carried forward the wrong
>>>>>>>>> value for years, and correcting it to its right value needs to do
>>>>>>>>> what?
>>>>>>>> We should stick to the wrong behavior for old machine types.
>>>>>>>>
>>>>>>>> That's all.
>>>>>>> So that means the following SD patch is also wrong (+Philippe) which
>>>>>>> changes the default value of capability register.
>>>>>>> http://patchwork.ozlabs.org/project/qemu-devel/patch/[e-mail]/
>>>>>> It should compat capareg for the old value for old machine types.
>>>>> Yeah, it's already a property for the SD controller model but someone
>>>>> views it as a bug because the model implements 64-bit but not
>>>>> reporting it in the capability register.
>>>>>
>>>>>>> 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.
>>>> That's the price for the stable ABI. See one of my recent fix -
>>>> d83f46d189 virtio-pci: compat page aligned ATS. It keeps the "buggy"
>>>> behavior to unbreak the migration.
>>>>
>>> But this series does not break the migration, as we discussed in the
>>> previous thread.
>>
>> It actually did,
>>
>> (qemu) qemu-kvm: get_pci_config_device: Bad config data: i=0x104 read:
>>       0 device: 20 cmask: ff wmask: 0 w1cmask:0
>>
>> Since the register is RO.
> Did you mean the VET register is read-only?


No, I meant for ATS.


> I don't understand this as
> the manual says it's RW and Linux driver programs it to 0x8100.


So ATS cap is read only so it can be validated by qemu.

VET is RW so qemu can't do similar checks.


>
>>
>>>>> 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")
>>>> I guess it's simply because fsl_etsec is not used in any
>>>> distributions/production environments or the maintainer may just not
>>>> notice things like this.
>>>>
>>>> But for e1000(e), we should stick to a stable ABI for consistency.
>>>> Otherwise it would be very tricky to fix them after we saw real issues.
>>>> We had learnt a lot during the past decade.
>>>>
>>> Okay, do we have such a kind of widely used device model list? And we
>>> should document such a process that we should keep compatibility on
>>> these devices as well.
>>
>> I can only say for networking devices:
>>
>> - e1000(e)
>> - rtl8139
>> - virtio-net
>>
> Please, at least have these documented as a development process.


See Peter's reply. We should take care of the devices that is involved 
in at least one versioned machine types.

If you wish, you can post a patch to clarify things in the doc.

Thanks


>
>>> Regarding this VET register, do you know what guest relies on the POR
>>> value which is zero?
>>
>> I don't know.
>>
>>
>>> Zero is not a valid ethernet VLAN type. I don't
>>> think changing this will break any guests.
>>
>> You might be right here, but it would be late if we find it breaks any one.
>>
>> If it's not a lot of work, I tend to bother with compat stuffs for this.
>>
> Regards,
> Bin
>

Jason Wang July 14, 2021, 9:24 a.m. UTC | #17

在 2021/7/14 下午5:14, Bin Meng 写道:
> On Wed, Jul 14, 2021 at 5:01 PM Peter Maydell <[e-mail]> wrote:
>> On Wed, 14 Jul 2021 at 04:42, Bin Meng <[e-mail]> wrote:
>>> On Wed, Jul 14, 2021 at 11:10 AM Jason Wang <[e-mail]> 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
>

Patch

diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 4f75b44cfc..20cbba6411 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -29,6 +29,7 @@ 
 #include "hw/pci/pci.h"
 #include "hw/qdev-properties.h"
 #include "migration/vmstate.h"
+#include "net/eth.h"
 #include "net/net.h"
 #include "net/checksum.h"
 #include "sysemu/sysemu.h"
@@ -254,6 +255,7 @@  static const uint32_t mac_reg_init[] = {
     [MANC]    = E1000_MANC_EN_MNG2HOST | E1000_MANC_RCV_TCO_EN |
                 E1000_MANC_ARP_EN | E1000_MANC_0298_EN |
                 E1000_MANC_RMCP_EN,
+    [VET]     = ETH_P_VLAN,
 };
 
 /* Helper function, *curr == 0 means the value is not set */