Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/10/2013 03:16 PM, Jason Wang wrote:
On Thursday, January 10, 2013 02:49:14 PM Wanlong Gao wrote:
On 01/10/2013 02:43 PM, Jason Wang wrote:
On Wednesday, January 09, 2013 11:26:33 PM Jason Wang wrote:
On 01/09/2013 06:01 PM, Wanlong Gao wrote:
On 01/09/2013 05:30 PM, Jason Wang wrote:
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type !=
NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
[...]
I got guest kernel panic when using this way and set queues=4.
Does it happens w/o or w/ a fd parameter? What's the qemu command line?
Did you meet it during boot time?
The QEMU command line is
/work/git/qemu/x86_64-softmmu/qemu-system-x86_64 -name f17 -M pc-0.15
-enable-kvm -m 3096 \ -smp 4,sockets=4,cores=1,threads=1 \
-uuid c31a9f3e-4161-c53a-339c-5dc36d0497cb -no-user-config -nodefaults \
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/f17.monitor,server,nowa
i
t \ -mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc -no-shutdown \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0xb,num_queues=4,hotplug=on \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
-drive file=/vm/f17.img,if=none,id=drive-virtio-disk0,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=v
i
rtio-disk0,bootindex=1 \ -drive
file=/vm2/f17-kernel.img,if=none,id=drive-virtio-disk1,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=v
i
rtio-disk1 \ -drive
file=/vm/virtio-scsi/scsi3.img,if=none,id=drive-scsi0-0-2-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-2-0,id
=
scsi0-0-2-0,removable=on \ -drive
file=/vm/virtio-scsi/scsi4.img,if=none,id=drive-scsi0-0-3-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-3-0,id
=
scsi0-0-3-0 \ -drive
file=/vm/virtio-scsi/scsi1.img,if=none,id=drive-scsi0-0-0-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id
=
scsi0-0-0-0 \ -drive
file=/vm/virtio-scsi/scsi2.img,if=none,id=drive-scsi0-0-1-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-1-0,id
=
scsi0-0-1-0 \ -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 \ -chardev
file,id=charserial1,path=/vm/f17.log \
-device isa-serial,chardev=charserial1,id=serial1 \
-device usb-tablet,id=input0 -vga std \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
-netdev tap,id=hostnet0,vhost=on,queues=4 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,a
d
dr=0x3 \ -monitor stdio
I got panic just after booting the system, did nothing, waited for a
while, the guest panicked.
[ 28.053004] BUG: soft lockup - CPU#1 stuck for 23s! [ip:592]
[ 28.053004] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables uinput
joydev microcode virtio_balloon pcspkr virtio_net i2c_piix4 i2c_core
virtio_scsi virtio_blk floppy [ 28.053004] CPU 1
[ 28.053004] Pid: 592, comm: ip Not tainted 3.8.0-rc1-net+ #3 Bochs
Bochs
[ 28.053004] RIP: 0010:[8137a9ab] [8137a9ab]
virtqueue_get_buf+0xb/0x120 [ 28.053004] RSP: 0018:8800bc913550
EFLAGS: 0246
[ 28.053004] RAX: RBX: 8800bc49c000 RCX:
8800bc49e000 [ 28.053004] RDX: RSI:
8800bc913584 RDI: 8800bcfd4000 [ 28.053004] RBP:
8800bc913558 R08: 8800bcfd0800 R09: [
28.053004] R10: 8800bc49c000 R11: 880036cc4de0 R12:
8800bcfd4000 [ 28.053004] R13: 8800bc913558 R14:
8137ad73 R15: 000200d0 [ 28.053004] FS:
7fb27a589740() GS:8800c148() knlGS:
[
28.053004] CS: 0010 DS: ES: CR0: 80050033
[ 28.053004] CR2: 00640530 CR3: baeff000 CR4:
06e0 [ 28.053004] DR0: DR1:
DR2: [ 28.053004] DR3:
DR6: 0ff0 DR7: 0400 [
28.053004] Process ip (pid: 592, threadinfo 8800bc912000, task
880036da2e20) [ 28.053004] Stack:
[ 28.053004] 8800bcfd0800 8800bc913638 a003e9bb
8800bc913656 [ 28.053004] 00010002 8800c17ebb08
0050ff10 ea0002f244c0 [ 28.053004] 00020582
ea0002f244c0 [
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/10/2013 05:06 PM, Wanlong Gao wrote:
On 01/10/2013 03:16 PM, Jason Wang wrote:
On Thursday, January 10, 2013 02:49:14 PM Wanlong Gao wrote:
On 01/10/2013 02:43 PM, Jason Wang wrote:
On Wednesday, January 09, 2013 11:26:33 PM Jason Wang wrote:
On 01/09/2013 06:01 PM, Wanlong Gao wrote:
On 01/09/2013 05:30 PM, Jason Wang wrote:
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type !=
NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
[...]
I got guest kernel panic when using this way and set queues=4.
Does it happens w/o or w/ a fd parameter? What's the qemu command line?
Did you meet it during boot time?
The QEMU command line is
/work/git/qemu/x86_64-softmmu/qemu-system-x86_64 -name f17 -M pc-0.15
-enable-kvm -m 3096 \ -smp 4,sockets=4,cores=1,threads=1 \
-uuid c31a9f3e-4161-c53a-339c-5dc36d0497cb -no-user-config -nodefaults \
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/f17.monitor,server,nowa
i
t \ -mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc -no-shutdown \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0xb,num_queues=4,hotplug=on \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
-drive file=/vm/f17.img,if=none,id=drive-virtio-disk0,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=v
i
rtio-disk0,bootindex=1 \ -drive
file=/vm2/f17-kernel.img,if=none,id=drive-virtio-disk1,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=v
i
rtio-disk1 \ -drive
file=/vm/virtio-scsi/scsi3.img,if=none,id=drive-scsi0-0-2-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-2-0,id
=
scsi0-0-2-0,removable=on \ -drive
file=/vm/virtio-scsi/scsi4.img,if=none,id=drive-scsi0-0-3-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-3-0,id
=
scsi0-0-3-0 \ -drive
file=/vm/virtio-scsi/scsi1.img,if=none,id=drive-scsi0-0-0-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id
=
scsi0-0-0-0 \ -drive
file=/vm/virtio-scsi/scsi2.img,if=none,id=drive-scsi0-0-1-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-1-0,id
=
scsi0-0-1-0 \ -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 \ -chardev
file,id=charserial1,path=/vm/f17.log \
-device isa-serial,chardev=charserial1,id=serial1 \
-device usb-tablet,id=input0 -vga std \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
-netdev tap,id=hostnet0,vhost=on,queues=4 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,a
d
dr=0x3 \ -monitor stdio
I got panic just after booting the system, did nothing, waited for a
while, the guest panicked.
[ 28.053004] BUG: soft lockup - CPU#1 stuck for 23s! [ip:592]
[ 28.053004] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables uinput
joydev microcode virtio_balloon pcspkr virtio_net i2c_piix4 i2c_core
virtio_scsi virtio_blk floppy [ 28.053004] CPU 1
[ 28.053004] Pid: 592, comm: ip Not tainted 3.8.0-rc1-net+ #3 Bochs
Bochs
[ 28.053004] RIP: 0010:[8137a9ab] [8137a9ab]
virtqueue_get_buf+0xb/0x120 [ 28.053004] RSP: 0018:8800bc913550
EFLAGS: 0246
[ 28.053004] RAX: RBX: 8800bc49c000 RCX:
8800bc49e000 [ 28.053004] RDX: RSI:
8800bc913584 RDI: 8800bcfd4000 [ 28.053004] RBP:
8800bc913558 R08: 8800bcfd0800 R09: [
28.053004] R10: 8800bc49c000 R11: 880036cc4de0 R12:
8800bcfd4000 [ 28.053004] R13: 8800bc913558 R14:
8137ad73 R15: 000200d0 [ 28.053004] FS:
7fb27a589740() GS:8800c148() knlGS:
[
28.053004] CS: 0010 DS: ES: CR0: 80050033
[ 28.053004] CR2: 00640530 CR3: baeff000 CR4:
06e0 [ 28.053004] DR0: DR1:
DR2: [ 28.053004] DR3:
DR6: 0ff0 DR7: 0400 [
28.053004] Process ip (pid: 592, threadinfo 8800bc912000, task
880036da2e20) [ 28.053004] Stack:
[ 28.053004] 8800bcfd0800 8800bc913638 a003e9bb
8800bc913656 [ 28.053004] 00010002 8800c17ebb08
0050ff10 ea0002f244c0 [ 28.053004] 00020582
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap
support.
I just can't start the QEMU use -netdev
tap,id=hostnet0,queues=2,fd=%d,fd=%d -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Can it create descriptors itself? I get
qemu-system-x86_64: -netdev tap,id=hostnet0,queues=2: Device 'tap' could not
be initialized
You need prepare an ifup script which default at /etc/qemu-ifup (like
following). Or you may try to add a script=no after:
#!/bin/sh
switch=kvmbr0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif $switch $1
/usr/sbin/brctl stp $switch off
This will let qemu create a tap fd itself and make it to be connected to
a port of the bridge caled kvmbr0.
But how to support multi-queue in this way?
I got guest kernel panic when using this way and set queues=4.
Thanks,
Wanlong Gao
I create the tap fd like this, and dup create the second fd, third fd, right?
The second and third fd should be created with TUNSETIFF with the same
tap_name also. Btw, you need to specify a IFF_MULTI_QUEUE flag to tell
the kernel you want to create a multiqueue tap device, otherwise the
second and third calling of TUNSETIFF will fail.
Thanks
int tap_fd = open(/dev/net/tun, O_RDWR);
int vhost_fd = open(/dev/vhost-net, O_RDWR);
char *tap_name = tap;
char cmd[2048];
char brctl[256];
char netup[256];
struct ifreq ifr;
if (tap_fd 0) {
printf(open tun device failed\n);
return -1;
}
if (vhost_fd 0) {
printf(open vhost-net device failed\n);
return -1;
}
memset(ifr, 0, sizeof(ifr));
memcpy(ifr.ifr_name, tap_name, sizeof(tap_name));
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
/*
* setup tap net device
*/
if (ioctl(tap_fd, TUNSETIFF, ifr) 0) {
printf(setup tap net device failed\n);
return -1;
}
sprintf(brctl, brctl addif virbr0 %s, tap_name);
sprintf(netup, ifconfig %s up, tap_name);
system(brctl);
system(netup);
Thanks,
Wanlong Gao
Thanks
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue,
int ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap
support.
I just can't start the QEMU use -netdev
tap,id=hostnet0,queues=2,fd=%d,fd=%d -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Can it create descriptors itself? I get
qemu-system-x86_64: -netdev tap,id=hostnet0,queues=2: Device 'tap' could
not be initialized
You need prepare an ifup script which default at /etc/qemu-ifup (like
following). Or you may try to add a script=no after:
#!/bin/sh
switch=kvmbr0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif $switch $1
/usr/sbin/brctl stp $switch off
This will let qemu create a tap fd itself and make it to be connected to
a port of the bridge caled kvmbr0.
But how to support multi-queue in this way?
Qemu will create the necessary multiqueue tap by itself, see patch 0/12.
I got guest kernel panic when using this way and set queues=4.
Does it happens w/o or w/ a fd parameter? What's the qemu command line?
Did you meet it during boot time?
Thanks
Thanks,
Wanlong Gao
I create the tap fd like this, and dup create the second fd, third fd,
right?
The second and third fd should be created with TUNSETIFF with the same
tap_name also. Btw, you need to specify a IFF_MULTI_QUEUE flag to tell
the kernel you want to create a multiqueue tap device, otherwise the
second and third calling of TUNSETIFF will fail.
Thanks
int tap_fd = open(/dev/net/tun, O_RDWR);
int vhost_fd = open(/dev/vhost-net, O_RDWR);
char *tap_name = tap;
char cmd[2048];
char brctl[256];
char netup[256];
struct ifreq ifr;
if (tap_fd 0) {
printf(open tun device failed\n);
return -1;
}
if (vhost_fd 0) {
printf(open vhost-net device failed\n);
return -1;
}
memset(ifr, 0, sizeof(ifr));
memcpy(ifr.ifr_name, tap_name, sizeof(tap_name));
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
/*
* setup tap net device
*/
if (ioctl(tap_fd, TUNSETIFF, ifr) 0) {
printf(setup tap net device failed\n);
return -1;
}
sprintf(brctl, brctl addif virbr0 %s, tap_name);
sprintf(netup, ifconfig %s up, tap_name);
system(brctl);
system(netup);
Thanks,
Wanlong Gao
Thanks
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue,
int ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/09/2013 05:30 PM, Jason Wang wrote:
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP)
{
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap
support.
I just can't start the QEMU use -netdev
tap,id=hostnet0,queues=2,fd=%d,fd=%d -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Can it create descriptors itself? I get
qemu-system-x86_64: -netdev tap,id=hostnet0,queues=2: Device 'tap' could
not be initialized
You need prepare an ifup script which default at /etc/qemu-ifup (like
following). Or you may try to add a script=no after:
#!/bin/sh
switch=kvmbr0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif $switch $1
/usr/sbin/brctl stp $switch off
This will let qemu create a tap fd itself and make it to be connected to
a port of the bridge caled kvmbr0.
But how to support multi-queue in this way?
Qemu will create the necessary multiqueue tap by itself, see patch 0/12.
I got guest kernel panic when using this way and set queues=4.
Does it happens w/o or w/ a fd parameter? What's the qemu command line?
Did you meet it during boot time?
The QEMU command line is
/work/git/qemu/x86_64-softmmu/qemu-system-x86_64 -name f17 -M pc-0.15
-enable-kvm -m 3096 \
-smp 4,sockets=4,cores=1,threads=1 \
-uuid c31a9f3e-4161-c53a-339c-5dc36d0497cb -no-user-config -nodefaults \
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/f17.monitor,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc -no-shutdown \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0xb,num_queues=4,hotplug=on \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
-drive file=/vm/f17.img,if=none,id=drive-virtio-disk0,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
\
-drive file=/vm2/f17-kernel.img,if=none,id=drive-virtio-disk1,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1
\
-drive file=/vm/virtio-scsi/scsi3.img,if=none,id=drive-scsi0-0-2-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-2-0,id=scsi0-0-2-0,removable=on
\
-drive file=/vm/virtio-scsi/scsi4.img,if=none,id=drive-scsi0-0-3-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-3-0,id=scsi0-0-3-0
\
-drive file=/vm/virtio-scsi/scsi1.img,if=none,id=drive-scsi0-0-0-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
\
-drive file=/vm/virtio-scsi/scsi2.img,if=none,id=drive-scsi0-0-1-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0
\
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 \
-chardev file,id=charserial1,path=/vm/f17.log \
-device isa-serial,chardev=charserial1,id=serial1 \
-device usb-tablet,id=input0 -vga std \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
-netdev tap,id=hostnet0,vhost=on,queues=4 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
\
-monitor stdio
I got panic just after booting the system, did nothing, waited for a while,
the guest panicked.
[ 28.053004] BUG: soft lockup - CPU#1 stuck for 23s! [ip:592]
[ 28.053004] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
xt_state nf_conntrack ip6table_filter ip6_tables uinput joydev microcode
virtio_balloon pcspkr virtio_net i2c_piix4 i2c_core virtio_scsi virtio_blk
floppy
[ 28.053004] CPU 1
[ 28.053004] Pid: 592, comm: ip Not tainted 3.8.0-rc1-net+ #3 Bochs
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/09/2013 06:01 PM, Wanlong Gao wrote:
On 01/09/2013 05:30 PM, Jason Wang wrote:
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type !=
NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this
assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap
support.
I just can't start the QEMU use -netdev
tap,id=hostnet0,queues=2,fd=%d,fd=%d -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Can it create descriptors itself? I get
qemu-system-x86_64: -netdev tap,id=hostnet0,queues=2: Device 'tap' could
not be initialized
You need prepare an ifup script which default at /etc/qemu-ifup (like
following). Or you may try to add a script=no after:
#!/bin/sh
switch=kvmbr0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif $switch $1
/usr/sbin/brctl stp $switch off
This will let qemu create a tap fd itself and make it to be connected to
a port of the bridge caled kvmbr0.
But how to support multi-queue in this way?
Qemu will create the necessary multiqueue tap by itself, see patch 0/12.
I got guest kernel panic when using this way and set queues=4.
Does it happens w/o or w/ a fd parameter? What's the qemu command line?
Did you meet it during boot time?
The QEMU command line is
/work/git/qemu/x86_64-softmmu/qemu-system-x86_64 -name f17 -M pc-0.15
-enable-kvm -m 3096 \
-smp 4,sockets=4,cores=1,threads=1 \
-uuid c31a9f3e-4161-c53a-339c-5dc36d0497cb -no-user-config -nodefaults \
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/f17.monitor,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc -no-shutdown \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0xb,num_queues=4,hotplug=on \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
-drive file=/vm/f17.img,if=none,id=drive-virtio-disk0,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
\
-drive file=/vm2/f17-kernel.img,if=none,id=drive-virtio-disk1,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1
\
-drive file=/vm/virtio-scsi/scsi3.img,if=none,id=drive-scsi0-0-2-0,format=raw
\
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-2-0,id=scsi0-0-2-0,removable=on
\
-drive file=/vm/virtio-scsi/scsi4.img,if=none,id=drive-scsi0-0-3-0,format=raw
\
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-3-0,id=scsi0-0-3-0
\
-drive file=/vm/virtio-scsi/scsi1.img,if=none,id=drive-scsi0-0-0-0,format=raw
\
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0
\
-drive file=/vm/virtio-scsi/scsi2.img,if=none,id=drive-scsi0-0-1-0,format=raw
\
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0
\
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0
\
-chardev file,id=charserial1,path=/vm/f17.log \
-device isa-serial,chardev=charserial1,id=serial1 \
-device usb-tablet,id=input0 -vga std \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
-netdev tap,id=hostnet0,vhost=on,queues=4 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
\
-monitor stdio
I got panic just after booting the system, did nothing, waited for a while,
the guest panicked.
[ 28.053004] BUG: soft lockup - CPU#1 stuck for 23s! [ip:592]
[ 28.053004] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables uinput joydev
microcode virtio_balloon pcspkr virtio_net i2c_piix4 i2c_core virtio_scsi
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On Wednesday, January 09, 2013 11:26:33 PM Jason Wang wrote:
On 01/09/2013 06:01 PM, Wanlong Gao wrote:
On 01/09/2013 05:30 PM, Jason Wang wrote:
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type !=
NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
[...]
I got guest kernel panic when using this way and set queues=4.
Does it happens w/o or w/ a fd parameter? What's the qemu command line?
Did you meet it during boot time?
The QEMU command line is
/work/git/qemu/x86_64-softmmu/qemu-system-x86_64 -name f17 -M pc-0.15
-enable-kvm -m 3096 \ -smp 4,sockets=4,cores=1,threads=1 \
-uuid c31a9f3e-4161-c53a-339c-5dc36d0497cb -no-user-config -nodefaults \
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/f17.monitor,server,nowai
t \ -mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc -no-shutdown \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0xb,num_queues=4,hotplug=on \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
-drive file=/vm/f17.img,if=none,id=drive-virtio-disk0,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=vi
rtio-disk0,bootindex=1 \ -drive
file=/vm2/f17-kernel.img,if=none,id=drive-virtio-disk1,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=vi
rtio-disk1 \ -drive
file=/vm/virtio-scsi/scsi3.img,if=none,id=drive-scsi0-0-2-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-2-0,id=
scsi0-0-2-0,removable=on \ -drive
file=/vm/virtio-scsi/scsi4.img,if=none,id=drive-scsi0-0-3-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-3-0,id=
scsi0-0-3-0 \ -drive
file=/vm/virtio-scsi/scsi1.img,if=none,id=drive-scsi0-0-0-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=
scsi0-0-0-0 \ -drive
file=/vm/virtio-scsi/scsi2.img,if=none,id=drive-scsi0-0-1-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-1-0,id=
scsi0-0-1-0 \ -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 \ -chardev
file,id=charserial1,path=/vm/f17.log \
-device isa-serial,chardev=charserial1,id=serial1 \
-device usb-tablet,id=input0 -vga std \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
-netdev tap,id=hostnet0,vhost=on,queues=4 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,ad
dr=0x3 \ -monitor stdio
I got panic just after booting the system, did nothing, waited for a
while, the guest panicked.
[ 28.053004] BUG: soft lockup - CPU#1 stuck for 23s! [ip:592]
[ 28.053004] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables uinput
joydev microcode virtio_balloon pcspkr virtio_net i2c_piix4 i2c_core
virtio_scsi virtio_blk floppy [ 28.053004] CPU 1
[ 28.053004] Pid: 592, comm: ip Not tainted 3.8.0-rc1-net+ #3 Bochs
Bochs
[ 28.053004] RIP: 0010:[8137a9ab] [8137a9ab]
virtqueue_get_buf+0xb/0x120 [ 28.053004] RSP: 0018:8800bc913550
EFLAGS: 0246
[ 28.053004] RAX: RBX: 8800bc49c000 RCX:
8800bc49e000 [ 28.053004] RDX: RSI:
8800bc913584 RDI: 8800bcfd4000 [ 28.053004] RBP:
8800bc913558 R08: 8800bcfd0800 R09: [
28.053004] R10: 8800bc49c000 R11: 880036cc4de0 R12:
8800bcfd4000 [ 28.053004] R13: 8800bc913558 R14:
8137ad73 R15: 000200d0 [ 28.053004] FS:
7fb27a589740() GS:8800c148() knlGS: [
28.053004] CS: 0010 DS: ES: CR0: 80050033
[ 28.053004] CR2: 00640530 CR3: baeff000 CR4:
06e0 [ 28.053004] DR0: DR1:
DR2: [ 28.053004] DR3:
DR6: 0ff0 DR7: 0400 [
28.053004] Process ip (pid: 592, threadinfo 8800bc912000, task
880036da2e20) [ 28.053004] Stack:
[ 28.053004] 8800bcfd0800 8800bc913638 a003e9bb
8800bc913656 [ 28.053004] 00010002 8800c17ebb08
0050ff10 ea0002f244c0 [ 28.053004] 00020582
ea0002f244c0 [ 28.053004] Call
Trace:
[ 28.053004]
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/10/2013 02:43 PM, Jason Wang wrote:
On Wednesday, January 09, 2013 11:26:33 PM Jason Wang wrote:
On 01/09/2013 06:01 PM, Wanlong Gao wrote:
On 01/09/2013 05:30 PM, Jason Wang wrote:
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type !=
NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
[...]
I got guest kernel panic when using this way and set queues=4.
Does it happens w/o or w/ a fd parameter? What's the qemu command line?
Did you meet it during boot time?
The QEMU command line is
/work/git/qemu/x86_64-softmmu/qemu-system-x86_64 -name f17 -M pc-0.15
-enable-kvm -m 3096 \ -smp 4,sockets=4,cores=1,threads=1 \
-uuid c31a9f3e-4161-c53a-339c-5dc36d0497cb -no-user-config -nodefaults \
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/f17.monitor,server,nowai
t \ -mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc -no-shutdown \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0xb,num_queues=4,hotplug=on \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
-drive file=/vm/f17.img,if=none,id=drive-virtio-disk0,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=vi
rtio-disk0,bootindex=1 \ -drive
file=/vm2/f17-kernel.img,if=none,id=drive-virtio-disk1,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=vi
rtio-disk1 \ -drive
file=/vm/virtio-scsi/scsi3.img,if=none,id=drive-scsi0-0-2-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-2-0,id=
scsi0-0-2-0,removable=on \ -drive
file=/vm/virtio-scsi/scsi4.img,if=none,id=drive-scsi0-0-3-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-3-0,id=
scsi0-0-3-0 \ -drive
file=/vm/virtio-scsi/scsi1.img,if=none,id=drive-scsi0-0-0-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=
scsi0-0-0-0 \ -drive
file=/vm/virtio-scsi/scsi2.img,if=none,id=drive-scsi0-0-1-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-1-0,id=
scsi0-0-1-0 \ -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 \ -chardev
file,id=charserial1,path=/vm/f17.log \
-device isa-serial,chardev=charserial1,id=serial1 \
-device usb-tablet,id=input0 -vga std \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
-netdev tap,id=hostnet0,vhost=on,queues=4 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,ad
dr=0x3 \ -monitor stdio
I got panic just after booting the system, did nothing, waited for a
while, the guest panicked.
[ 28.053004] BUG: soft lockup - CPU#1 stuck for 23s! [ip:592]
[ 28.053004] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables uinput
joydev microcode virtio_balloon pcspkr virtio_net i2c_piix4 i2c_core
virtio_scsi virtio_blk floppy [ 28.053004] CPU 1
[ 28.053004] Pid: 592, comm: ip Not tainted 3.8.0-rc1-net+ #3 Bochs
Bochs
[ 28.053004] RIP: 0010:[8137a9ab] [8137a9ab]
virtqueue_get_buf+0xb/0x120 [ 28.053004] RSP: 0018:8800bc913550
EFLAGS: 0246
[ 28.053004] RAX: RBX: 8800bc49c000 RCX:
8800bc49e000 [ 28.053004] RDX: RSI:
8800bc913584 RDI: 8800bcfd4000 [ 28.053004] RBP:
8800bc913558 R08: 8800bcfd0800 R09: [
28.053004] R10: 8800bc49c000 R11: 880036cc4de0 R12:
8800bcfd4000 [ 28.053004] R13: 8800bc913558 R14:
8137ad73 R15: 000200d0 [ 28.053004] FS:
7fb27a589740() GS:8800c148() knlGS: [
28.053004] CS: 0010 DS: ES: CR0: 80050033
[ 28.053004] CR2: 00640530 CR3: baeff000 CR4:
06e0 [ 28.053004] DR0: DR1:
DR2: [ 28.053004] DR3:
DR6: 0ff0 DR7: 0400 [
28.053004] Process ip (pid: 592, threadinfo 8800bc912000, task
880036da2e20) [ 28.053004] Stack:
[ 28.053004] 8800bcfd0800 8800bc913638 a003e9bb
8800bc913656 [ 28.053004] 00010002 8800c17ebb08
0050ff10 ea0002f244c0 [ 28.053004] 00020582
ea0002f244c0 [ 28.053004] Call
Trace:
[ 28.053004] [a003e9bb]
virtnet_send_command.constprop.26+0x24b/0x270
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On Thursday, January 10, 2013 02:49:14 PM Wanlong Gao wrote:
On 01/10/2013 02:43 PM, Jason Wang wrote:
On Wednesday, January 09, 2013 11:26:33 PM Jason Wang wrote:
On 01/09/2013 06:01 PM, Wanlong Gao wrote:
On 01/09/2013 05:30 PM, Jason Wang wrote:
On 01/09/2013 04:23 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type !=
NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
[...]
I got guest kernel panic when using this way and set queues=4.
Does it happens w/o or w/ a fd parameter? What's the qemu command line?
Did you meet it during boot time?
The QEMU command line is
/work/git/qemu/x86_64-softmmu/qemu-system-x86_64 -name f17 -M pc-0.15
-enable-kvm -m 3096 \ -smp 4,sockets=4,cores=1,threads=1 \
-uuid c31a9f3e-4161-c53a-339c-5dc36d0497cb -no-user-config -nodefaults \
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/f17.monitor,server,nowa
i
t \ -mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc -no-shutdown \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-device
virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0xb,num_queues=4,hotplug=on \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
-drive file=/vm/f17.img,if=none,id=drive-virtio-disk0,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=v
i
rtio-disk0,bootindex=1 \ -drive
file=/vm2/f17-kernel.img,if=none,id=drive-virtio-disk1,format=qcow2 \
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=v
i
rtio-disk1 \ -drive
file=/vm/virtio-scsi/scsi3.img,if=none,id=drive-scsi0-0-2-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-2-0,id
=
scsi0-0-2-0,removable=on \ -drive
file=/vm/virtio-scsi/scsi4.img,if=none,id=drive-scsi0-0-3-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=3,drive=drive-scsi0-0-3-0,id
=
scsi0-0-3-0 \ -drive
file=/vm/virtio-scsi/scsi1.img,if=none,id=drive-scsi0-0-0-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id
=
scsi0-0-0-0 \ -drive
file=/vm/virtio-scsi/scsi2.img,if=none,id=drive-scsi0-0-1-0,format=raw \
-device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-1-0,id
=
scsi0-0-1-0 \ -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 \ -chardev
file,id=charserial1,path=/vm/f17.log \
-device isa-serial,chardev=charserial1,id=serial1 \
-device usb-tablet,id=input0 -vga std \
-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
-netdev tap,id=hostnet0,vhost=on,queues=4 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,a
d
dr=0x3 \ -monitor stdio
I got panic just after booting the system, did nothing, waited for a
while, the guest panicked.
[ 28.053004] BUG: soft lockup - CPU#1 stuck for 23s! [ip:592]
[ 28.053004] Modules linked in: ip6t_REJECT nf_conntrack_ipv6
nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables uinput
joydev microcode virtio_balloon pcspkr virtio_net i2c_piix4 i2c_core
virtio_scsi virtio_blk floppy [ 28.053004] CPU 1
[ 28.053004] Pid: 592, comm: ip Not tainted 3.8.0-rc1-net+ #3 Bochs
Bochs
[ 28.053004] RIP: 0010:[8137a9ab] [8137a9ab]
virtqueue_get_buf+0xb/0x120 [ 28.053004] RSP: 0018:8800bc913550
EFLAGS: 0246
[ 28.053004] RAX: RBX: 8800bc49c000 RCX:
8800bc49e000 [ 28.053004] RDX: RSI:
8800bc913584 RDI: 8800bcfd4000 [ 28.053004] RBP:
8800bc913558 R08: 8800bcfd0800 R09: [
28.053004] R10: 8800bc49c000 R11: 880036cc4de0 R12:
8800bcfd4000 [ 28.053004] R13: 8800bc913558 R14:
8137ad73 R15: 000200d0 [ 28.053004] FS:
7fb27a589740() GS:8800c148() knlGS:
[
28.053004] CS: 0010 DS: ES: CR0: 80050033
[ 28.053004] CR2: 00640530 CR3: baeff000 CR4:
06e0 [ 28.053004] DR0: DR1:
DR2: [ 28.053004] DR3:
DR6: 0ff0 DR7: 0400 [
28.053004] Process ip (pid: 592, threadinfo 8800bc912000, task
880036da2e20) [ 28.053004] Stack:
[ 28.053004] 8800bcfd0800 8800bc913638 a003e9bb
8800bc913656 [ 28.053004] 00010002 8800c17ebb08
0050ff10 ea0002f244c0 [
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330: virtio_net_set_queues:
Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap support.
I just can't start the QEMU use -netdev tap,id=hostnet0,queues=2,fd=%d,fd=%d
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap support.
I just can't start the QEMU use -netdev tap,id=hostnet0,queues=2,fd=%d,fd=%d
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Thanks
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
It may because my host doesn't support muti-tap, I'll try with the upstream
kernel again.
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap support.
I just can't start the QEMU use -netdev
tap,id=hostnet0,queues=2,fd=%d,fd=%d -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Can it create descriptors itself? I get
qemu-system-x86_64: -netdev tap,id=hostnet0,queues=2: Device 'tap' could not be
initialized
I create the tap fd like this, and dup create the second fd, third fd, right?
int tap_fd = open(/dev/net/tun, O_RDWR);
int vhost_fd = open(/dev/vhost-net, O_RDWR);
char *tap_name = tap;
char cmd[2048];
char brctl[256];
char netup[256];
struct ifreq ifr;
if (tap_fd 0) {
printf(open tun device failed\n);
return -1;
}
if (vhost_fd 0) {
printf(open vhost-net device failed\n);
return -1;
}
memset(ifr, 0, sizeof(ifr));
memcpy(ifr.ifr_name, tap_name, sizeof(tap_name));
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
/*
* setup tap net device
*/
if (ioctl(tap_fd, TUNSETIFF, ifr) 0) {
printf(setup tap net device failed\n);
return -1;
}
sprintf(brctl, brctl addif virbr0 %s, tap_name);
sprintf(netup, ifconfig %s up, tap_name);
system(brctl);
system(netup);
Thanks,
Wanlong Gao
Thanks
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap
support.
I just can't start the QEMU use -netdev
tap,id=hostnet0,queues=2,fd=%d,fd=%d -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Can it create descriptors itself? I get
qemu-system-x86_64: -netdev tap,id=hostnet0,queues=2: Device 'tap' could not
be initialized
You need prepare an ifup script which default at /etc/qemu-ifup (like
following). Or you may try to add a script=no after:
#!/bin/sh
switch=kvmbr0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif $switch $1
/usr/sbin/brctl stp $switch off
This will let qemu create a tap fd itself and make it to be connected to
a port of the bridge caled kvmbr0.
I create the tap fd like this, and dup create the second fd, third fd, right?
The second and third fd should be created with TUNSETIFF with the same
tap_name also. Btw, you need to specify a IFF_MULTI_QUEUE flag to tell
the kernel you want to create a multiqueue tap device, otherwise the
second and third calling of TUNSETIFF will fail.
Thanks
int tap_fd = open(/dev/net/tun, O_RDWR);
int vhost_fd = open(/dev/vhost-net, O_RDWR);
char *tap_name = tap;
char cmd[2048];
char brctl[256];
char netup[256];
struct ifreq ifr;
if (tap_fd 0) {
printf(open tun device failed\n);
return -1;
}
if (vhost_fd 0) {
printf(open vhost-net device failed\n);
return -1;
}
memset(ifr, 0, sizeof(ifr));
memcpy(ifr.ifr_name, tap_name, sizeof(tap_name));
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
/*
* setup tap net device
*/
if (ioctl(tap_fd, TUNSETIFF, ifr) 0) {
printf(setup tap net device failed\n);
return -1;
}
sprintf(brctl, brctl addif virbr0 %s, tap_name);
sprintf(netup, ifconfig %s up, tap_name);
system(brctl);
system(netup);
Thanks,
Wanlong Gao
Thanks
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap
support.
I just can't start the QEMU use -netdev
tap,id=hostnet0,queues=2,fd=%d,fd=%d -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Can it create descriptors itself? I get
qemu-system-x86_64: -netdev tap,id=hostnet0,queues=2: Device 'tap' could not
be initialized
You need prepare an ifup script which default at /etc/qemu-ifup (like
following). Or you may try to add a script=no after:
#!/bin/sh
switch=kvmbr0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif $switch $1
/usr/sbin/brctl stp $switch off
This will let qemu create a tap fd itself and make it to be connected to
a port of the bridge caled kvmbr0.
I create the tap fd like this, and dup create the second fd, third fd, right?
The second and third fd should be created with TUNSETIFF with the same
tap_name also. Btw, you need to specify a IFF_MULTI_QUEUE flag to tell
the kernel you want to create a multiqueue tap device, otherwise the
second and third calling of TUNSETIFF will fail.
Thank you for teaching me, I'll try it tomorrow.
Regards,
Wanlong Gao
Thanks
int tap_fd = open(/dev/net/tun, O_RDWR);
int vhost_fd = open(/dev/vhost-net, O_RDWR);
char *tap_name = tap;
char cmd[2048];
char brctl[256];
char netup[256];
struct ifreq ifr;
if (tap_fd 0) {
printf(open tun device failed\n);
return -1;
}
if (vhost_fd 0) {
printf(open vhost-net device failed\n);
return -1;
}
memset(ifr, 0, sizeof(ifr));
memcpy(ifr.ifr_name, tap_name, sizeof(tap_name));
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
/*
* setup tap net device
*/
if (ioctl(tap_fd, TUNSETIFF, ifr) 0) {
printf(setup tap net device failed\n);
return -1;
}
sprintf(brctl, brctl addif virbr0 %s, tap_name);
sprintf(netup, ifconfig %s up, tap_name);
system(brctl);
system(netup);
Thanks,
Wanlong Gao
Thanks
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue,
int ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 01/08/2013 07:24 PM, Wanlong Gao wrote:
On 01/08/2013 06:14 PM, Jason Wang wrote:
On 01/08/2013 06:00 PM, Wanlong Gao wrote:
On 01/08/2013 05:51 PM, Jason Wang wrote:
On 01/08/2013 05:49 PM, Wanlong Gao wrote:
On 01/08/2013 05:29 PM, Jason Wang wrote:
On 01/08/2013 05:07 PM, Wanlong Gao wrote:
On 12/28/2012 06:32 PM, Jason Wang wrote:
+} else if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
+ret = -1;
+} else {
+ret = tap_detach(nc-peer);
+}
+
+return ret;
+}
+
+static void virtio_net_set_queues(VirtIONet *n)
+{
+int i;
+
+for (i = 0; i n-max_queues; i++) {
+if (i n-curr_queues) {
+assert(!peer_attach(n, i));
+} else {
+assert(!peer_detach(n, i));
I got a assert here,
qemu-system-x86_64: /work/git/qemu/hw/virtio-net.c:330:
virtio_net_set_queues: Assertion `!peer_detach(n, i)' failed.
Any thoughts?
Thanks,
Wanlong Gao
Thanks for the testing, which steps or cases did you met this assertion,
migration, reboot or just changing the number of virtqueues?
I use the 3.8-rc2 to test it again, I saw this tag has the multi-tap
support.
I just can't start the QEMU use -netdev
tap,id=hostnet0,queues=2,fd=%d,fd=%d -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:ce:7b:29,bus=pci.0,addr=0x3
I pre-opened two tap fds, did I missing something?
Nothing missed :) It should work.
Could you please try not use fd=X and let qemu to create the file
descriptors by itself? Btw, how did you create the two tap fds?
Can it create descriptors itself? I get
qemu-system-x86_64: -netdev tap,id=hostnet0,queues=2: Device 'tap' could
not be initialized
You need prepare an ifup script which default at /etc/qemu-ifup (like
following). Or you may try to add a script=no after:
#!/bin/sh
switch=kvmbr0
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif $switch $1
/usr/sbin/brctl stp $switch off
This will let qemu create a tap fd itself and make it to be connected to
a port of the bridge caled kvmbr0.
I create the tap fd like this, and dup create the second fd, third fd,
right?
The second and third fd should be created with TUNSETIFF with the same
tap_name also. Btw, you need to specify a IFF_MULTI_QUEUE flag to tell
the kernel you want to create a multiqueue tap device, otherwise the
second and third calling of TUNSETIFF will fail.
Thank you for teaching me, I'll try it tomorrow.
Regards,
Wanlong Gao
Thanks, the API of multiqueue should be documented in
Documentation/networking/tuntap.txt. It's in my TODO list.
Thanks
int tap_fd = open(/dev/net/tun, O_RDWR);
int vhost_fd = open(/dev/vhost-net, O_RDWR);
char *tap_name = tap;
char cmd[2048];
char brctl[256];
char netup[256];
struct ifreq ifr;
if (tap_fd 0) {
printf(open tun device failed\n);
return -1;
}
if (vhost_fd 0) {
printf(open vhost-net device failed\n);
return -1;
}
memset(ifr, 0, sizeof(ifr));
memcpy(ifr.ifr_name, tap_name, sizeof(tap_name));
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
/*
* setup tap net device
*/
if (ioctl(tap_fd, TUNSETIFF, ifr) 0) {
printf(setup tap net device failed\n);
return -1;
}
sprintf(brctl, brctl addif virbr0 %s, tap_name);
sprintf(netup, ifconfig %s up, tap_name);
system(brctl);
system(netup);
Thanks,
Wanlong Gao
Thanks
Thanks,
Wanlong Gao
+}
+}
+}
+
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue,
int ctrl);
+
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On Fri, Jan 4, 2013 at 5:12 AM, Jason Wang jasow...@redhat.com wrote:
On 12/29/2012 01:52 AM, Blue Swirl wrote:
On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang jasow...@redhat.com wrote:
This patch implements both userspace and vhost support for multiple queue
virtio-net (VIRTIO_NET_F_MQ). This is done by introducing an array of
VirtIONetQueue to VirtIONet.
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/virtio-net.c | 318
++-
hw/virtio-net.h | 27 +-
2 files changed, 271 insertions(+), 74 deletions(-)
[...]
static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIONet *n = to_virtio_net(vdev);
@@ -464,6 +578,8 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev,
VirtQueue *vq)
status = virtio_net_handle_mac(n, ctrl.cmd, elem);
else if (ctrl.class == VIRTIO_NET_CTRL_VLAN)
status = virtio_net_handle_vlan_table(n, ctrl.cmd, elem);
+else if (ctrl.class == VIRTIO_NET_CTRL_MQ)
Please add braces.
Sure.
+status = virtio_net_handle_mq(n, ctrl.cmd, elem);
stb_p(elem.in_sg[elem.in_num - 1].iov_base, status);
@@ -477,19 +593,24 @@ static void virtio_net_handle_ctrl(VirtIODevice
*vdev, VirtQueue *vq)
static void virtio_net_handle_rx(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIONet *n = to_virtio_net(vdev);
+int queue_index = vq2q(virtio_get_queue_index(vq));
-qemu_flush_queued_packets(qemu_get_queue(n-nic));
+qemu_flush_queued_packets(qemu_get_subqueue(n-nic, queue_index));
}
[...]
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl)
+{
+VirtIODevice *vdev = n-vdev;
+int i;
+
+n-multiqueue = multiqueue;
+
+if (!multiqueue)
+n-curr_queues = 1;
Ditto. Didn't checkpatch.pl catch these or did you not check?
Sorry, will add braces here. I run checkpatch.pl but finally find that
some or lots of the existed codes (such as this file) does not obey the
rules. So I'm not sure whether I need to correct my own codes, or left
them as this file does and correct them all in the future.
The goal is to make QEMU codebase conform to CODING_STYLE. Currently
this is not the case for some amounts of code, but we should use
opportunities like this to advance towards that goal.
[...]
} QEMU_PACKED;
/* This is the first element of the scatter-gather list. If you don't
@@ -168,6 +172,26 @@ struct virtio_net_ctrl_mac {
#define VIRTIO_NET_CTRL_VLAN_ADD 0
#define VIRTIO_NET_CTRL_VLAN_DEL 1
+/*
+ * Control Multiqueue
+ *
+ * The command VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
+ * enables multiqueue, specifying the number of the transmit and
+ * receive queues that will be used. After the command is consumed and
acked by
+ * the device, the device will not steer new packets on receive virtqueues
+ * other than specified nor read from transmit virtqueues other than
specified.
+ * Accordingly, driver should not transmit new packets on virtqueues
other than
+ * specified.
+ */
+struct virtio_net_ctrl_mq {
VirtIONetCtrlMQ and please don't forget the typedef.
Sure, but the same question as above. (See other structures in this file).
+uint16_t virtqueue_pairs;
+};
+
+#define VIRTIO_NET_CTRL_MQ 4
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET0
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MIN1
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX0x8000
+
#define DEFINE_VIRTIO_NET_FEATURES(_state, _field) \
DEFINE_VIRTIO_COMMON_FEATURES(_state, _field), \
DEFINE_PROP_BIT(csum, _state, _field, VIRTIO_NET_F_CSUM, true), \
@@ -186,5 +210,6 @@ struct virtio_net_ctrl_mac {
DEFINE_PROP_BIT(ctrl_vq, _state, _field, VIRTIO_NET_F_CTRL_VQ,
true), \
DEFINE_PROP_BIT(ctrl_rx, _state, _field, VIRTIO_NET_F_CTRL_RX,
true), \
DEFINE_PROP_BIT(ctrl_vlan, _state, _field,
VIRTIO_NET_F_CTRL_VLAN, true), \
-DEFINE_PROP_BIT(ctrl_rx_extra, _state, _field,
VIRTIO_NET_F_CTRL_RX_EXTRA, true)
+DEFINE_PROP_BIT(ctrl_rx_extra, _state, _field,
VIRTIO_NET_F_CTRL_RX_EXTRA, true), \
+DEFINE_PROP_BIT(mq, _state, _field, VIRTIO_NET_F_MQ, true)
#endif
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On 12/29/2012 01:52 AM, Blue Swirl wrote:
On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang jasow...@redhat.com wrote:
This patch implements both userspace and vhost support for multiple queue
virtio-net (VIRTIO_NET_F_MQ). This is done by introducing an array of
VirtIONetQueue to VirtIONet.
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/virtio-net.c | 318
++-
hw/virtio-net.h | 27 +-
2 files changed, 271 insertions(+), 74 deletions(-)
[...]
static void virtio_net_handle_ctrl(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIONet *n = to_virtio_net(vdev);
@@ -464,6 +578,8 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev,
VirtQueue *vq)
status = virtio_net_handle_mac(n, ctrl.cmd, elem);
else if (ctrl.class == VIRTIO_NET_CTRL_VLAN)
status = virtio_net_handle_vlan_table(n, ctrl.cmd, elem);
+else if (ctrl.class == VIRTIO_NET_CTRL_MQ)
Please add braces.
Sure.
+status = virtio_net_handle_mq(n, ctrl.cmd, elem);
stb_p(elem.in_sg[elem.in_num - 1].iov_base, status);
@@ -477,19 +593,24 @@ static void virtio_net_handle_ctrl(VirtIODevice *vdev,
VirtQueue *vq)
static void virtio_net_handle_rx(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIONet *n = to_virtio_net(vdev);
+int queue_index = vq2q(virtio_get_queue_index(vq));
-qemu_flush_queued_packets(qemu_get_queue(n-nic));
+qemu_flush_queued_packets(qemu_get_subqueue(n-nic, queue_index));
}
[...]
+static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue, int
ctrl)
+{
+VirtIODevice *vdev = n-vdev;
+int i;
+
+n-multiqueue = multiqueue;
+
+if (!multiqueue)
+n-curr_queues = 1;
Ditto. Didn't checkpatch.pl catch these or did you not check?
Sorry, will add braces here. I run checkpatch.pl but finally find that
some or lots of the existed codes (such as this file) does not obey the
rules. So I'm not sure whether I need to correct my own codes, or left
them as this file does and correct them all in the future.
[...]
} QEMU_PACKED;
/* This is the first element of the scatter-gather list. If you don't
@@ -168,6 +172,26 @@ struct virtio_net_ctrl_mac {
#define VIRTIO_NET_CTRL_VLAN_ADD 0
#define VIRTIO_NET_CTRL_VLAN_DEL 1
+/*
+ * Control Multiqueue
+ *
+ * The command VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
+ * enables multiqueue, specifying the number of the transmit and
+ * receive queues that will be used. After the command is consumed and
acked by
+ * the device, the device will not steer new packets on receive virtqueues
+ * other than specified nor read from transmit virtqueues other than
specified.
+ * Accordingly, driver should not transmit new packets on virtqueues other
than
+ * specified.
+ */
+struct virtio_net_ctrl_mq {
VirtIONetCtrlMQ and please don't forget the typedef.
Sure, but the same question as above. (See other structures in this file).
+uint16_t virtqueue_pairs;
+};
+
+#define VIRTIO_NET_CTRL_MQ 4
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET0
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MIN1
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX0x8000
+
#define DEFINE_VIRTIO_NET_FEATURES(_state, _field) \
DEFINE_VIRTIO_COMMON_FEATURES(_state, _field), \
DEFINE_PROP_BIT(csum, _state, _field, VIRTIO_NET_F_CSUM, true), \
@@ -186,5 +210,6 @@ struct virtio_net_ctrl_mac {
DEFINE_PROP_BIT(ctrl_vq, _state, _field, VIRTIO_NET_F_CTRL_VQ,
true), \
DEFINE_PROP_BIT(ctrl_rx, _state, _field, VIRTIO_NET_F_CTRL_RX,
true), \
DEFINE_PROP_BIT(ctrl_vlan, _state, _field,
VIRTIO_NET_F_CTRL_VLAN, true), \
-DEFINE_PROP_BIT(ctrl_rx_extra, _state, _field,
VIRTIO_NET_F_CTRL_RX_EXTRA, true)
+DEFINE_PROP_BIT(ctrl_rx_extra, _state, _field,
VIRTIO_NET_F_CTRL_RX_EXTRA, true), \
+DEFINE_PROP_BIT(mq, _state, _field, VIRTIO_NET_F_MQ, true)
#endif
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 10/12] virtio-net: multiqueue support
On Fri, Dec 28, 2012 at 10:32 AM, Jason Wang jasow...@redhat.com wrote:
This patch implements both userspace and vhost support for multiple queue
virtio-net (VIRTIO_NET_F_MQ). This is done by introducing an array of
VirtIONetQueue to VirtIONet.
Signed-off-by: Jason Wang jasow...@redhat.com
---
hw/virtio-net.c | 318
++-
hw/virtio-net.h | 27 +-
2 files changed, 271 insertions(+), 74 deletions(-)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index c6f0915..aaeef1b 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -45,7 +45,7 @@ typedef struct VirtIONet
VirtIODevice vdev;
uint8_t mac[ETH_ALEN];
uint16_t status;
-VirtIONetQueue vq;
+VirtIONetQueue vqs[MAX_QUEUE_NUM];
VirtQueue *ctrl_vq;
NICState *nic;
uint32_t tx_timeout;
@@ -70,14 +70,23 @@ typedef struct VirtIONet
} mac_table;
uint32_t *vlans;
DeviceState *qdev;
+int multiqueue;
+uint16_t max_queues;
+uint16_t curr_queues;
} VirtIONet;
-static VirtIONetQueue *virtio_net_get_queue(NetClientState *nc)
+static VirtIONetQueue *virtio_net_get_subqueue(NetClientState *nc)
{
VirtIONet *n = qemu_get_nic_opaque(nc);
-return n-vq;
+return n-vqs[nc-queue_index];
}
+
+static int vq2q(int queue_index)
+{
+return queue_index / 2;
+}
+
/* TODO
* - we could suppress RX interrupt if we were so inclined.
*/
@@ -93,6 +102,7 @@ static void virtio_net_get_config(VirtIODevice *vdev,
uint8_t *config)
struct virtio_net_config netcfg;
stw_p(netcfg.status, n-status);
+stw_p(netcfg.max_virtqueue_pairs, n-max_queues);
memcpy(netcfg.mac, n-mac, ETH_ALEN);
memcpy(config, netcfg, sizeof(netcfg));
}
@@ -116,31 +126,33 @@ static bool virtio_net_started(VirtIONet *n, uint8_t
status)
(n-status VIRTIO_NET_S_LINK_UP) n-vdev.vm_running;
}
-static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)
+static void virtio_net_vhost_status(VirtIONet *n, int queue_index,
+uint8_t status)
{
-VirtIONetQueue *q = n-vq;
+NetClientState *nc = qemu_get_subqueue(n-nic, queue_index);
+VirtIONetQueue *q = n-vqs[queue_index];
-if (!qemu_get_queue(n-nic)-peer) {
+if (!nc-peer) {
return;
}
-if (qemu_get_queue(n-nic)-peer-info-type !=
NET_CLIENT_OPTIONS_KIND_TAP) {
+if (nc-peer-info-type != NET_CLIENT_OPTIONS_KIND_TAP) {
return;
}
-if (!tap_get_vhost_net(qemu_get_queue(n-nic)-peer)) {
+if (!tap_get_vhost_net(nc-peer)) {
return;
}
-if (!!q-vhost_started == virtio_net_started(n, status)
- !qemu_get_queue(n-nic)-peer-link_down) {
+if (!!q-vhost_started ==
+(virtio_net_started(n, status) !nc-peer-link_down)) {
return;
}
if (!q-vhost_started) {
int r;
-if
(!vhost_net_query(tap_get_vhost_net(qemu_get_queue(n-nic)-peer), n-vdev))
{
+if (!vhost_net_query(tap_get_vhost_net(nc-peer), n-vdev)) {
return;
}
-r = vhost_net_start(tap_get_vhost_net(qemu_get_queue(n-nic)-peer),
-n-vdev, 0);
+r = vhost_net_start(tap_get_vhost_net(nc-peer), n-vdev,
+queue_index * 2);
if (r 0) {
error_report(unable to start vhost net: %d:
falling back on userspace virtio, -r);
@@ -148,7 +160,7 @@ static void virtio_net_vhost_status(VirtIONet *n, uint8_t
status)
q-vhost_started = 1;
}
} else {
-vhost_net_stop(tap_get_vhost_net(qemu_get_queue(n-nic)-peer),
n-vdev);
+vhost_net_stop(tap_get_vhost_net(nc-peer), n-vdev);
q-vhost_started = 0;
}
}
@@ -156,26 +168,35 @@ static void virtio_net_vhost_status(VirtIONet *n,
uint8_t status)
static void virtio_net_set_status(struct VirtIODevice *vdev, uint8_t status)
{
VirtIONet *n = to_virtio_net(vdev);
-VirtIONetQueue *q = n-vq;
+int i;
-virtio_net_vhost_status(n, status);
+for (i = 0; i n-max_queues; i++) {
+VirtIONetQueue *q = n-vqs[i];
+uint8_t queue_status = status;
-if (!q-tx_waiting) {
-return;
-}
+if ((!n-multiqueue i != 0) || i = n-curr_queues) {
+queue_status = 0;
+}
-if (virtio_net_started(n, status) !q-vhost_started) {
-if (q-tx_timer) {
-qemu_mod_timer(q-tx_timer,
- qemu_get_clock_ns(vm_clock) + n-tx_timeout);
-} else {
-qemu_bh_schedule(q-tx_bh);
+virtio_net_vhost_status(n, i, queue_status);
+
+if (!q-tx_waiting) {
+continue;
}
-} else {
-if (q-tx_timer) {
-qemu_del_timer(q-tx_timer);
+
+if (virtio_net_started(n, status)
