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;
}
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.