qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Mark McLoughlin <markmc@redhat.com>
To: qemu-devel@nongnu.org
Cc: dlaor@redhat.com
Subject: Re: [Qemu-devel] e1000, virtio_net: Check link status in can_receive
Date: Tue, 14 Apr 2009 09:18:09 +0100	[thread overview]
Message-ID: <1239697089.18289.64.camel@blaa> (raw)
In-Reply-To: <009201c9bba3$5addabb0$10990310$@com>

On Sun, 2009-04-12 at 05:17 -0400, Yan Vugenfirer wrote:

> From: Yan Vugenfirer <yvugenfi@redhat.com>
> Date: Sun, 5 Apr 2009 10:20:53 -0400
> Subject: [PATCH 1/1] e1000, virtio_net: Check link status in can_receive
> 
> Fixing the bug of 100% cpu usage by qemu after using "set_link <NIC> down" 
> monitor command. The fix is for virtio_net and for e1000 emulations.
> 
> ---
>  hw/e1000.c      |    3 ++-
>  hw/virtio-net.c |    3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/e1000.c b/hw/e1000.c
> index 1644201..36878d9 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -590,7 +590,8 @@ e1000_can_receive(void *opaque)
>  {
>      E1000State *s = opaque;
>  
> -    return (s->mac_reg[RCTL] & E1000_RCTL_EN);
> +    return (s->mac_reg[RCTL] & E1000_RCTL_EN) &&
> +           (s->mac_reg[STATUS] & E1000_STATUS_LU);
>  }
>  
>  static void
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index ad55bb7..dcd18c1 100644
> --- a/hw/virtio-net.c
> +++ b/hw/virtio-net.c
> @@ -259,7 +259,8 @@ static void virtio_net_handle_rx(VirtIODevice *vdev, VirtQueue *vq)
>  static int do_virtio_net_can_receive(VirtIONet *n, int bufsize)
>  {
>      if (!virtio_queue_ready(n->rx_vq) ||
> -        !(n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK))
> +        !(n->vdev.status & VIRTIO_CONFIG_S_DRIVER_OK) ||
> +        !(n->status & VIRTIO_NET_S_LINK_UP))
>          return 0;
>  
>      if (virtio_queue_empty(n->rx_vq) ||

Firstly, I think this "100% CPU" bug is specific to kvm - we have some
code in kvm's tree to buffer tap packets which causes this, I think. I
have some qemu patches in the works to remove this difference between
the trees.

Your patch does make some sense, but I think what we really want is for
qemu_send_packet() to drop the tap packet when virtio/e1000 is down.
This is the behaviour we have in the other direction. Does the patch
below fix the problem for you?

Thanks,
Mark.

diff --git a/qemu/net.c b/qemu/net.c
index 4d07905..95fd808 100644
--- a/qemu/net.c
+++ b/qemu/net.c
@@ -409,8 +409,10 @@ int qemu_send_packet(VLANClientState *vc1, const uint8_t *buf, int size)
     hex_dump(stdout, buf, size);
 #endif
     for(vc = vlan->first_client; vc != NULL; vc = vc->next) {
-        if (vc != vc1 && !vc->link_down) {
-            if (!vc->fd_can_read || vc->fd_can_read(vc->opaque)) {
+        if (vc != vc1) {
+            if (vc->link_down)
+                ret = 0;
+            else if (!vc->fd_can_read || vc->fd_can_read(vc->opaque)) {
                 vc->fd_read(vc->opaque, buf, size);
                 ret = 0;
             }

  reply	other threads:[~2009-04-14  8:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-12  9:17 [Qemu-devel] e1000, virtio_net: Check link status in can_receive Yan Vugenfirer
2009-04-14  8:18 ` Mark McLoughlin [this message]
2009-04-16 10:10   ` Yan Vugenfirer
2009-04-18 14:52 ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1239697089.18289.64.camel@blaa \
    --to=markmc@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).