On 2015/11/4 11:19, Jason Wang wrote:
On 11/04/2015 10:24 AM, zhanghailiang wrote:
On 2015/11/3 22:54, Marc-André Lureau wrote:
Hi
On Tue, Nov 3, 2015 at 2:01 PM, zhanghailiang
<zhang.zhanghaili...@huawei.com> wrote:
The corresponding codes where gdb reports error are: (We have added
some
codes in net.c)
Can you reproduce with unmodified qemu? Could you give instructions
to do so?
OK, i will try to do it. There is nothing special, we run iperf tool
in VM,
and then shutdown or reboot it. There is change you can catch segfault.
ssize_t qemu_deliver_packet(NetClientState *sender,
unsigned flags,
const uint8_t *data,
size_t size,
void *opaque)
{
NetClientState *nc = opaque;
ssize_t ret;
if (nc->link_down) {
return size;
}
if (nc->receive_disabled) {
return 0;
}
if (flags & QEMU_NET_PACKET_FLAG_RAW && nc->info->receive_raw) {
ret = nc->info->receive_raw(nc, data, size);
} else {
ret = nc->info->receive(nc, data, size); ----> Here is
510 line
}
I'm not quite familiar with vhost-user, but for vhost-user, these two
callback functions seem to be always NULL,
Why we can come here ?
You should not come here, vhost-user has nc->receive_disabled (it
changes in 2.5)
I have looked at the newest codes, i think we can still have chance to
come here, since we will change nc->receive_disable to false
temporarily in
qemu_flush_or_purge_queued_packets(), there is no difference between
2.3 and 2.5
for this.
Besides, is it possible for !QTAILQ_EMPTY(&queue->packets) to be true
in qemu_net_queue_flush() for vhost-user ?
The only thing I can image is self announcing. Are you trying to do
migration? 2.5 only support sending rarp through this.
Hmm, it's not triggered by migration, For qemu-2.5, IMHO, it doesn't have such
problem,
since the callback function 'receive' is not NULL. It is vhost_user_receive().
And it's better to have a breakpoint to see why a packet was queued for
vhost-user. The stack trace may also help in this case.
OK, i'm trying to reproduce it.
Thanks,
zhanghailiang
i will try to reproduce it by using newest qemu.
Thanks,
zhanghailiang
.
