Bug 890288

This problem can also be reproduced by this steps:

1. boot a guest with e1000 / rtl8139 nic (pause guest by -S option)
2. set link down by monitor
  (qemu) set_link ... off
3. continue guest
  (qemu) c
4. check link status in guest

I tried with latest guest kernel (3.6.10-2.fc17.x86_64, driver updated) & latest upstream qemu

+ virtio-net:
  after reboot, link status is down in guest, network is unavailable.
+ rtl8139:
  after reboot, link status is unexpectedly up in guest, network is unavailable.
+e1000: (guest reboot will reset qemu setup)
  after reboot, link will be reset to be up, and network is (unexpectedly) available.

(In reply to comment #3)
> I tried with latest guest kernel (3.6.10-2.fc17.x86_64, driver updated) &
> latest upstream qemu
> 
> + virtio-net:
>   after reboot, link status is down in guest, network is unavailable.
> + rtl8139:
>   after reboot, link status is unexpectedly up in guest, network is
> unavailable.
> +e1000: (guest reboot will reset qemu setup)
>   after reboot, link will be reset to be up, and network is (unexpectedly)
> available.

Need to check whether the link status were preserved during reset for 8139. For e1000, I remember that there's a patch to preserved the link status, need to check whether the link status negotiation emulation patch has side effect of this.

Thanks

For e1000, link auto-negotiation emulation will always set link up in e1000_autoneg_timer, it's a regression bug, can be fixed by this patch:

diff --git a/hw/e1000.c b/hw/e1000.c
index 5537ad2..a3b602e 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -164,6 +164,10 @@ static void
 set_phy_ctrl(E1000State *s, int index, uint16_t val)
 {
     if ((val & MII_CR_AUTO_NEG_EN) && (val & MII_CR_RESTART_AUTO_NEG)) {
+        if (s->nic->nc.link_down) {
+            s->phy_reg[PHY_STATUS] |= MII_SR_AUTONEG_COMPLETE;
+            return;
+        }
         s->nic->nc.link_down = true;
         e1000_link_down(s);
         s->phy_reg[PHY_STATUS] &= ~MII_SR_AUTONEG_COMPLETE;

Posted two patches to upstream:
http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg03555.html

  e1000: no need auto-negotiation if link was down
  rtl8139: preserve link state across device reset

(tested with wxp & rhel6 guests)

Hi Ademar,

> +e1000: (guest reboot will reset qemu setup)
>   after reboot, link will be reset to be up, and network is (unexpectedly)
> available.

^^^ rhel6 kernel & qemu-kvm-rhel6 also got this result

So if Admin limits VM user network by set_link, user can smartly re-got network by a reboot

For e1000, it is a regression introduced in RHEL6.4 by this commit:
so I agree to bug this bz in 6.4 by exception+

| commit ebfdba95f6fd2719dda11f4ebd9267af270e921b
| Author: Xiao Wang <jasowang>
| Date:   Fri Aug 10 09:03:49 2012 -0300
| 
|     e1000: link auto-negotiation emulation

(In reply to comment #7)
> For e1000, it is a regression introduced in RHEL6.4 by this commit:
> so I agree to bug this bz in 6.4 by exception+
> 
> | commit ebfdba95f6fd2719dda11f4ebd9267af270e921b
> | Author: Xiao Wang <jasowang>
> | Date:   Fri Aug 10 09:03:49 2012 -0300
> | 
> |     e1000: link auto-negotiation emulation

Thanks for the details. Adding Regression keyword and requesting the blocker flag.

Verify this bug on qemu-kvm-0.12.1.2-2.349.el6.x86_64 with the comment #0 steps.

host info:
kernel-2.6.32-351.el6.x86_64
qemu-kvm-0.12.1.2-2.349.el6.x86_64
guest info:
kernel-2.6.32-351.el6.x86_64

steps:
the same to comment #0

Results:
after step 5, the rtl8139/e1000 network card's status is still 'down' status after reboot guest, and the network is unavailable.

Base on above, this issue has been fixed correctly.

http://marc.info/?t=135967653900002&r=1&w=3

Michael Roth (mdroth.ibm.com) raised a possible problem in upstream, I will track on it.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0527.html