qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] [BUG or NOT] NICs in up state can not receive any pac


From: Jakob Bohm
Subject: Re: [Qemu-discuss] [BUG or NOT] NICs in up state can not receive any packages if other one NIC is in down state
Date: Mon, 20 Aug 2012 17:22:59 +0200
User-agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 8/20/2012 10:14 AM, Rongqing Li wrote:

On 2012年08月20日 16:03, Stefan Hajnoczi wrote:
On Mon, Aug 20, 2012 at 02:26:33PM +0800, Rongqing Li wrote:


On 2012年08月17日 16:06, Stefan Hajnoczi wrote:
On Fri, Aug 17, 2012 at 09:38:45AM +0800, Rongqing Li wrote:


On 2012年08月16日 20:57, Stefan Hajnoczi wrote:
I think the solution is not to drop Vincent/Zhi Yong's code. Instead we should distinguish between "up" and "down". If a net client is "up" but cannot receive, then the hub will queue the packet. If a net client is
"down" then the hub will ignore the client and send packets to other
clients.

I don't have patches for this but have added it to my TODO list.

Stefan

Ok, Thanks for you explanation! and expect your patch.

If you have time to fix this I suggest you try to submit the patch
because I may not get to within the next week.

We need a way to determine whether the interface is up/down.  There is
already a link_down flag that can be set. Not sure if its semantics are
exactly what we need, you'd need to check net.h/net.c.

The second step is looking at qemu_can_send_packet() and .can_receive().
net/hub.c:net_hub_port_can_receive() needs to be tweaked so peers with
link_down are skipped.

Stefan

Hi Stefan:

Seem the link_down flags can not report if NIC is in down or in
up status.

Down the NIC by "ifconfig eth0 down", but link_down still is 0,
and "mii-tool eth0" says link is ready.

To e1000 dev, only "s->mac_reg[RCTL] & E1000_RCTL_EN" is 0 after
down it.

I did not find other flags and methods which reflect the NIC
up/down status.

Okay.  The link_down flag seems to have different semantics from what we
want.

I think we need a "receive disabled" flag.


we have a receive_disabled flag, but it is not what we expect.

If we want to add some new flags, we seem to need do it for all network
device.

This is the wrong approach altogether.

What you should do is:

1. Back out the "deadlock all NICs if one NIC is busy" logic,
it is really harmful to those of us who use qemu-based
emulators (qemu-system, qemu-kvm, qemu-xen) for production
server virtualization.  Sometimes hosted at 3rd parties who
do not provide access to the virtual machines console, thus
making the virtual computer completely unfixable if the
network is gone.

2. Add a receive queue to the virtual USB NIC code, so it can
keep up with the other virtual NICs.

3. For any virtual NIC, if the Guest OS does not consume
packets as fast as they arrive, for a period exceeding the
expected CPU overhead jitter (which should determine the
size of the packet queue inside the qemu driver), then
that Guest OS should expect lost packets, just like on
real hardware.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded




reply via email to

[Prev in Thread] Current Thread [Next in Thread]