Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-1218

Boot guest with e1000e, value of "/sys/class/net/$nic/operstate" is wrongly showed as "up" after "(qemu) set_link net0 off"

XMLWordPrintable

    • qemu-kvm-8.0.0-16.el9_3
    • None
    • Low
    • rhel-sst-virtualization-networking
    • ssg_virtualization
    • 1
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • If docs needed, set a value
    • None

      Description of problem:
      Boot guest with e1000e. After executing "(qemu) set_link net0 off", the value of "/sys/class/net/$nic/operstate" in guest is 'up'. but the expected value is 'down'.

      Version-Release number of selected component (if applicable):
      4.18.0-82.el8.x86_64
      qemu-kvm-2.12.0-69.module+el8.1.0+3143+457f984c.x86_64

      How reproducible:
      100%

      Steps to Reproduce:
      1. Boot guest with e1000e

      -netdev tap,id=hostnet0 \
      -device e1000e,netdev=hostnet0,id=net0,mac=fa:5e:07:b4:08:01,bus=root.2 \

      2. In qemu terminal, set this NIC link off
      (qemu) set_link net0 off

      3. In guest, check status, it's wrongly showed "up".

      1. ifconfig
        ens2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.73.74.39 netmask 255.255.252.0 broadcast 10.73.75.255
        inet6 fe80::f85e:7ff:feb4:801 prefixlen 64 scopeid 0x20<link>
        ether fa:5e:07:b4:08:01 txqueuelen 1000 (Ethernet)
        RX packets 81602 bytes 6158528 (5.8 MiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 268 bytes 758903 (741.1 KiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        device interrupt 23 memory 0xfe640000-fe660000
      1. cat /sys/class/net/ens2/operstate
        up

      Actual results:
      The value of /sys/class/net/$nic/operstate is wrongly showed "up" after set link down.

      Expected results:
      The value of /sys/class/net/$nic/operstate should be showed "down" after set link down.

      Additional info:
      1. virtio-net-pci works well. So it's only e1000e issue.

      Reference:
      1. Full cmd line:

      /usr/libexec/qemu-kvm -name rhel8.0 \
      -M q35,kernel-irqchip=split \
      -cpu host -m 8G \
      -smp 4,sockets=1,cores=4,threads=1 \
      -device pcie-root-port,id=root.1,slot=1 \
      -device pcie-root-port,id=root.2,slot=2 \
      -drive file=/home/rhel8.0.qcow2,format=qcow2,if=none,id=drive-virtio-blk0,werror=stop,rerror=stop \
      -device virtio-blk-pci,drive=drive-virtio-blk0,id=virtio-blk0,bus=root.1 \
      -vnc :2 \
      -monitor stdio \
      -netdev tap,id=hostnet0 \
      -device e1000e,netdev=hostnet0,id=net0,mac=fa:5e:07:b4:08:01,bus=root.2 \

            [RHEL-1218] Boot guest with e1000e, value of "/sys/class/net/$nic/operstate" is wrongly showed as "up" after "(qemu) set_link net0 off"

            Errata Tool added a comment -

            Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

            For information on the advisory (Moderate: qemu-kvm security, bug fix, and enhancement update), and where to find the updated files, follow the link below.

            If the solution does not work for you, open a new bug report.
            https://access.redhat.com/errata/RHSA-2023:6368

            Errata Tool added a comment - Since the problem described in this issue should be resolved in a recent advisory, it has been closed. For information on the advisory (Moderate: qemu-kvm security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:6368

            Lei Yang added a comment -

            according to comment 23073079, could you set "Preliminary Testing:Pass"?

            Done

            Lei Yang added a comment - according to comment 23073079, could you set "Preliminary Testing:Pass"? Done

            Laurent Vivier added a comment - - edited

            rhn-support-leiyang ,

            according to comment 23073079, could you set "Preliminary Testing:Pass"?

            Thanks

            Laurent Vivier added a comment - - edited rhn-support-leiyang , according to comment 23073079 , could you set "Preliminary Testing:Pass"? Thanks

            Yan Vugenfirer added a comment -

            Adjusting "Fix Version/s:" based on the test result.

            Yan Vugenfirer added a comment - Adjusting "Fix Version/s:" based on the test result.

            Lei Yang added a comment -

            The following commit fixed this bug:

            ['virtual_network']commit e414270000e9f7fe2a56d314ab85259aeaf1bd91
Author: Akihiko Odaki <akihiko.odaki@daynix.com>
Date:   Fri Jun 2 16:25:16 2023 +0900    e1000e: Add ICR clearing by corresponding IMS bit
    
    The datasheet does not say what happens when interrupt was asserted
    (ICR.INT_ASSERT=1) and auto mask is *not* active.
    However, section of 13.3.27 the PCIe* GbE Controllers Open Source
    Software Developer’s Manual, which were written for older devices,
    namely 631xESB/632xESB, 82563EB/82564EB, 82571EB/82572EI &
    82573E/82573V/82573L, does say:
    > If IMS = 0b, then the ICR register is always clear-on-read. If IMS is
    > not 0b, but some ICR bit is set where the corresponding IMS bit is not
    > set, then a read does not clear the ICR register. For example, if
    > IMS = 10101010b and ICR = 01010101b, then a read to the ICR register
    > does not clear it. If IMS = 10101010b and ICR = 0101011b, then a read
    > to the ICR register clears it entirely (ICR.INT_ASSERTED = 1b).
    
    Linux does no longer activate auto mask since commit
    0a8047ac68e50e4ccbadcfc6b6b070805b976885 and the real hardware clears
    ICR even in such a case so we also should do so.
    
    Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441
    Signed-off-by: Andrew Melnychenko <andrew@daynix.com>
    Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>

            Lei Yang added a comment - The following commit fixed this bug: ['virtual_network']commit e414270000e9f7fe2a56d314ab85259aeaf1bd91 Author: Akihiko Odaki <akihiko.odaki@daynix.com> Date:   Fri Jun 2 16:25:16 2023 +0900    e1000e: Add ICR clearing by corresponding IMS bit          The datasheet does not say what happens when interrupt was asserted     (ICR.INT_ASSERT=1) and auto mask is *not* active.     However, section of 13.3.27 the PCIe* GbE Controllers Open Source     Software Developer’s Manual, which were written for older devices,     namely 631xESB/632xESB, 82563EB/82564EB, 82571EB/82572EI &     82573E/82573V/82573L, does say:     > If IMS = 0b, then the ICR register is always clear-on-read. If IMS is     > not 0b, but some ICR bit is set where the corresponding IMS bit is not     > set, then a read does not clear the ICR register. For example, if     > IMS = 10101010b and ICR = 01010101b, then a read to the ICR register     > does not clear it. If IMS = 10101010b and ICR = 0101011b, then a read     > to the ICR register clears it entirely (ICR.INT_ASSERTED = 1b).          Linux does no longer activate auto mask since commit     0a8047ac68e50e4ccbadcfc6b6b070805b976885 and the real hardware clears     ICR even in such a case so we also should do so.          Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441     Signed-off-by: Andrew Melnychenko <andrew@daynix.com>     Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>     Signed-off-by: Jason Wang <jasowang@redhat.com>

            Lei Yang added a comment -

            ==>Reproduced this problem on qemu-kvm-8.0.0-16.el9_3.x86_64

            1. Boot up a guest with e1000e device

            -device '{"driver": "e1000e", "mac": "00:11:22:33:44:00", "id": "net0", "netdev": "hostnet0", "bus": "pcie-root-port-3", "addr": "0x0"}'  \
            -netdev tap,id=hostnet0 \

            2.  In qemu terminal, set this NIC link off

            (qemu) set_link net0 off 

            3. In guest, check status, it's wrongly showed "up"

            1. cat /sys/class/net/eth0/operstate
              up

            ==> So based on the above test result,successfully reproduced this bug on qemu-kvm-8.0.0-16.el9_3.x86_64

             

            ==> Verified this bug on qemu-kvm-8.1.0-1.el9.x86_64

            1. Repeated the above 1~2 steps

            2. In guest, check status, it show the correctly status "down".

            1. cat /sys/class/net/eth0/operstate
              down

             

            So based on the above test result this bug has been fixed very well on  qemu-kvm-8.1.0-1.el9.x86_64. So move to Release Pending status.

            Lei Yang added a comment - ==>Reproduced this problem on qemu-kvm-8.0.0-16.el9_3.x86_64 1. Boot up a guest with e1000e device -device '{"driver": "e1000e", "mac": "00:11:22:33:44:00", "id": "net0", "netdev": "hostnet0", "bus": "pcie-root-port-3", "addr": "0x0"}'  \ -netdev tap,id=hostnet0 \ 2.  In qemu terminal, set this NIC link off (qemu) set_link net0 off  3. In guest, check status, it's wrongly showed "up" cat /sys/class/net/eth0/operstate up ==> So based on the above test result,successfully reproduced this bug on qemu-kvm-8.0.0-16.el9_3.x86_64   ==> Verified this bug on qemu-kvm-8.1.0-1.el9.x86_64 1. Repeated the above 1~2 steps 2. In guest, check status, it show the correctly status "down". cat /sys/class/net/eth0/operstate down   So based on the above test result this bug has been fixed very well on  qemu-kvm-8.1.0-1.el9.x86_64. So move to Release Pending status.

            Akihiko Odaki added a comment -

            The fix is merged upstream: https://gitlab.com/qemu-project/qemu/-/commit/e414270000e9f7fe2a56d314ab85259aeaf1bd91

            Akihiko Odaki added a comment - The fix is merged upstream: https://gitlab.com/qemu-project/qemu/-/commit/e414270000e9f7fe2a56d314ab85259aeaf1bd91

            Lei Yang added a comment -

            Hit same issue

            Test Version:
            kernel-5.14.0-307.el9.x86_64
            qemu-kvm-8.0.0-1.el9.x86_64
            edk2-ovmf-20230301gitf80f052277c8-2.el9.noarch

            Lei Yang added a comment - Hit same issue Test Version: kernel-5.14.0-307.el9.x86_64 qemu-kvm-8.0.0-1.el9.x86_64 edk2-ovmf-20230301gitf80f052277c8-2.el9.noarch

            Lei Yang added a comment -

            Hit same issue

            Test Version:
            kernel-5.14.0-226.el9.x86_64
            qemu-kvm-7.2.0-2.el9.x86_64
            edk2-ovmf-20221207gitfff6d81270b5-1.el9.noarch

            Lei Yang added a comment - Hit same issue Test Version: kernel-5.14.0-226.el9.x86_64 qemu-kvm-7.2.0-2.el9.x86_64 edk2-ovmf-20221207gitfff6d81270b5-1.el9.noarch

            Yan Vugenfirer added a comment -

            Upstream work continues.

            Yan Vugenfirer added a comment - Upstream work continues.

              yvugenfi@redhat.com Yan Vugenfirer
              rhn-support-pezhang Pei Zhang
              virt-maint virt-maint
              Lei Yang Lei Yang
              Votes:
              0 Vote for this issue
              Watchers:
              18 Start watching this issue

                Created:
                Updated:
                Resolved: