* [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug @ 2013-03-05 6:55 Alexey Kardashevskiy 2013-03-05 12:56 ` Michael S. Tsirkin 0 siblings, 1 reply; 9+ messages in thread From: Alexey Kardashevskiy @ 2013-03-05 6:55 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: rusty, qemu-devel@nongnu.org, David Gibson Hi! The patch f56a12475ff1b8aa61210d08522c3c8aaf0e2648 "vhost: backend masking support" breaks virtio-net + vhost=on on PPC64 platform. The problem command line is: 1) -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh,vhost=on \ -device virtio-net-pci,netdev=tapnet,addr=0.0 \ Without the patch, the eth0 in the guest works fine, with the patch it simply does not. The guest's eth0 also works with the following configs: 2) new -netdev interface with vhost=off: -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh \ -device virtio-net-pci,netdev=tapnet,addr=0.0 3) old -net interface with vhost=on: -net tap,ifname=tap0,script=qemu-ifup.sh,vhost=on \ -net nic,model=virtio,addr=0:0:0 4) old -net interface with vhost=off: -net tap,ifname=tap0,script=qemu-ifup.sh \ -net nic,model=virtio,addr=0:0:0 I run http://junkcode.samba.org/ftp/unpacked/junkcode/socklib/ on 10Gb ethernet and observe 1020MB/s for 1) (without the patch), 800MB/s for 2), 70MB/s for 3) and 4). The virtio features (cat /sys/bus/virtio/devices/virtio0/features) for 1) and 2) are: "1100011111111111111100000000110000000000000000000000000000000000" and for 3) and 4) they are: "0000011000000001111100000000110000000000000000000000000000000000" I guess this is because the old -net interface creates an internal hub as "info qtree" shows vlan=0 and netdev=hub0port1 while the new -netdev interface does not seem to create any internal hub (vlan=<null>, netdev=tapnet). btw why are the configs so different? The network config is below. Both host and guest are running 3.8 kernel. The qemu tree from qemu.org/master still has this problem. What am I missing? Thanks. The full command line is like below plus the network config from the examples above: sudo qemu-impreza/ppc64-softmmu/qemu-system-ppc64 -m 1024 -machine pseries,kernel_irqchip=on -trace events=trace_events \ -nographic -vga none -enable-kvm -kernel vml38_64k -initrd 1.cpio This is the host config: [aik@vpl2 ~]$ cat qemu-ifup.sh #! /bin/sh /sbin/ifconfig $1 0.0.0.0 promisc up /usr/sbin/brctl addif brtest $1 [aik@vpl2 ~]$ brctl show bridge name bridge id STP enabled interfaces brtest 8000.00145e992e88 no eth0 [aik@vpl2 ~]$ ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::214:5eff:fe99:2e88 prefixlen 64 scopeid 0x20<link> ether 00:14:5e:99:2e:88 txqueuelen 1000 (Ethernet) RX packets 1781219 bytes 124692636 (118.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 13734906 bytes 20755102658 (19.3 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 49 memory 0x3c0500800000-3c0500800fff [aik@vpl2 ~]$ lspci -vs 1:1:0.0 0001:01:00.0 Ethernet controller: Chelsio Communications Inc T310 10GbE Single Port Adapter Subsystem: IBM Device 038c Flags: bus master, fast devsel, latency 0, IRQ 49 Memory at 3c0500800000 (64-bit, non-prefetchable) [size=4K] Memory at 3c0500000000 (64-bit, non-prefetchable) [size=8M] Memory at 3c0500801000 (64-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 3c0500c00000 [disabled] [size=512K] Capabilities: <access denied> Kernel driver in use: cxgb3 [aik@vpl2 ~]$ ls -l /sys/bus/pci/devices/0001\:01\:00.0/net/ total 0 drwxr-xr-x. 5 root root 0 Mar 5 12:59 eth0 [aik@vpl2 ~]$ uname -a Linux vpl2.ozlabs.ibm.com 3.8.0-kvm-64k-aik+ #239 SMP Tue Mar 5 12:50:05 EST 2013 ppc64 ppc64 ppc64 GNU/Linux This is the running guest: root@erif_root:~# lspci -v 00:00.0 Ethernet controller: Qumranet, Inc. Virtio network device Subsystem: Qumranet, Inc. Device 0001 Flags: bus master, fast devsel, latency 0, IRQ 19 I/O ports at 0020 [size=32] Memory at 100b0000000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 100b0010000 [disabled] [size=64K] Capabilities: [40] MSI-X: Enable+ Count=3 Masked- Kernel driver in use: virtio-pci root@erif_root:~# ifconfig -a eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 inet addr:172.20.1.2 Bcast:172.20.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:36 errors:0 dropped:6 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2268 (2.2 KiB) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) root@erif_root:~# uname -a Linux erif_root 3.8.0-aik-guest+ #262 SMP Mon Mar 4 15:58:55 EST 2013 ppc64 GNU/Linux -- Alexey ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug 2013-03-05 6:55 [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug Alexey Kardashevskiy @ 2013-03-05 12:56 ` Michael S. Tsirkin 2013-03-05 13:21 ` Alexey Kardashevskiy 0 siblings, 1 reply; 9+ messages in thread From: Michael S. Tsirkin @ 2013-03-05 12:56 UTC (permalink / raw) To: Alexey Kardashevskiy; +Cc: rusty, qemu-devel@nongnu.org, David Gibson On Tue, Mar 05, 2013 at 05:55:19PM +1100, Alexey Kardashevskiy wrote: > Hi! > > The patch f56a12475ff1b8aa61210d08522c3c8aaf0e2648 "vhost: backend > masking support" breaks virtio-net + vhost=on on PPC64 platform. > > The problem command line is: > 1) -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh,vhost=on \ > -device virtio-net-pci,netdev=tapnet,addr=0.0 \ I think the issue is irqfd in not supported on kvm ppc. Could you please check this: + /* If guest supports masking, set up irqfd now. + * Otherwise, delay until unmasked in the frontend. + */ + if (proxy->vdev->guest_notifier_mask) { + ret = kvm_virtio_pci_irqfd_use(proxy, queue_no, vector); + if (ret < 0) { + kvm_virtio_pci_vq_vector_release(proxy, vector); + goto undo; + } + } Could you please add a printf before "undo" and check whether the error path above is triggered? > Without the patch, the eth0 in the guest works fine, with the patch > it simply does not. The guest's eth0 also works with the following > configs: > > 2) new -netdev interface with vhost=off: > -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh \ > -device virtio-net-pci,netdev=tapnet,addr=0.0 > > 3) old -net interface with vhost=on: > -net tap,ifname=tap0,script=qemu-ifup.sh,vhost=on \ > -net nic,model=virtio,addr=0:0:0 > > 4) old -net interface with vhost=off: > -net tap,ifname=tap0,script=qemu-ifup.sh \ > -net nic,model=virtio,addr=0:0:0 > > I run http://junkcode.samba.org/ftp/unpacked/junkcode/socklib/ on > 10Gb ethernet and observe 1020MB/s for 1) (without the patch), > 800MB/s for 2), 70MB/s for 3) and 4). > > The virtio features (cat /sys/bus/virtio/devices/virtio0/features) > for 1) and 2) are: > "1100011111111111111100000000110000000000000000000000000000000000" > and for 3) and 4) they are: > "0000011000000001111100000000110000000000000000000000000000000000" > > > I guess this is because the old -net interface creates > an internal hub as "info qtree" shows vlan=0 and netdev=hub0port1 > while the new -netdev interface does not seem to create any internal > hub (vlan=<null>, netdev=tapnet). btw why are the configs so different? > > The network config is below. Both host and guest are running 3.8 kernel. > The qemu tree from qemu.org/master still has this problem. > > > What am I missing? Thanks. > > > The full command line is like below plus the network config from > the examples above: > > sudo qemu-impreza/ppc64-softmmu/qemu-system-ppc64 -m 1024 -machine > pseries,kernel_irqchip=on -trace events=trace_events \ > -nographic -vga none -enable-kvm -kernel vml38_64k -initrd 1.cpio > > > This is the host config: > > [aik@vpl2 ~]$ cat qemu-ifup.sh > #! /bin/sh > > /sbin/ifconfig $1 0.0.0.0 promisc up > /usr/sbin/brctl addif brtest $1 > > [aik@vpl2 ~]$ brctl show > bridge name bridge id STP enabled interfaces > brtest 8000.00145e992e88 no eth0 > [aik@vpl2 ~]$ ifconfig eth0 > eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet6 fe80::214:5eff:fe99:2e88 prefixlen 64 scopeid 0x20<link> > ether 00:14:5e:99:2e:88 txqueuelen 1000 (Ethernet) > RX packets 1781219 bytes 124692636 (118.9 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 13734906 bytes 20755102658 (19.3 GiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > device interrupt 49 memory 0x3c0500800000-3c0500800fff > > [aik@vpl2 ~]$ lspci -vs 1:1:0.0 > 0001:01:00.0 Ethernet controller: Chelsio Communications Inc T310 > 10GbE Single Port Adapter > Subsystem: IBM Device 038c > Flags: bus master, fast devsel, latency 0, IRQ 49 > Memory at 3c0500800000 (64-bit, non-prefetchable) [size=4K] > Memory at 3c0500000000 (64-bit, non-prefetchable) [size=8M] > Memory at 3c0500801000 (64-bit, non-prefetchable) [size=4K] > [virtual] Expansion ROM at 3c0500c00000 [disabled] [size=512K] > Capabilities: <access denied> > Kernel driver in use: cxgb3 > > [aik@vpl2 ~]$ ls -l /sys/bus/pci/devices/0001\:01\:00.0/net/ > total 0 > drwxr-xr-x. 5 root root 0 Mar 5 12:59 eth0 > [aik@vpl2 ~]$ uname -a > Linux vpl2.ozlabs.ibm.com 3.8.0-kvm-64k-aik+ #239 SMP Tue Mar 5 > 12:50:05 EST 2013 ppc64 ppc64 ppc64 GNU/Linux > > > This is the running guest: > > root@erif_root:~# lspci -v > 00:00.0 Ethernet controller: Qumranet, Inc. Virtio network device > Subsystem: Qumranet, Inc. Device 0001 > Flags: bus master, fast devsel, latency 0, IRQ 19 > I/O ports at 0020 [size=32] > Memory at 100b0000000 (32-bit, non-prefetchable) [size=4K] > Expansion ROM at 100b0010000 [disabled] [size=64K] > Capabilities: [40] MSI-X: Enable+ Count=3 Masked- > Kernel driver in use: virtio-pci > > root@erif_root:~# ifconfig -a > eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 > inet addr:172.20.1.2 Bcast:172.20.255.255 Mask:255.255.0.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:36 errors:0 dropped:6 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:2268 (2.2 KiB) TX bytes:0 (0.0 B) > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:65536 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > root@erif_root:~# uname -a > Linux erif_root 3.8.0-aik-guest+ #262 SMP Mon Mar 4 15:58:55 EST > 2013 ppc64 GNU/Linux > > > -- > Alexey ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug 2013-03-05 12:56 ` Michael S. Tsirkin @ 2013-03-05 13:21 ` Alexey Kardashevskiy 2013-03-05 14:23 ` Michael S. Tsirkin 0 siblings, 1 reply; 9+ messages in thread From: Alexey Kardashevskiy @ 2013-03-05 13:21 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: rusty, qemu-devel@nongnu.org, David Gibson On 05/03/13 23:56, Michael S. Tsirkin wrote: >> The patch f56a12475ff1b8aa61210d08522c3c8aaf0e2648 "vhost: backend >> masking support" breaks virtio-net + vhost=on on PPC64 platform. >> >> The problem command line is: >> 1) -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh,vhost=on \ >> -device virtio-net-pci,netdev=tapnet,addr=0.0 \ > > I think the issue is irqfd in not supported on kvm ppc. How can I make sure this is the case? Some work has been done there recently but midnight is quite late to figure this out :) > Could you please check this: > > + /* If guest supports masking, set up irqfd now. > + * Otherwise, delay until unmasked in the frontend. > + */ > + if (proxy->vdev->guest_notifier_mask) { > + ret = kvm_virtio_pci_irqfd_use(proxy, queue_no, vector); > + if (ret < 0) { > + kvm_virtio_pci_vq_vector_release(proxy, vector); > + goto undo; > + } > + } > > > Could you please add a printf before "undo" and check whether the > error path above is triggered? Checked, it is not triggered. -- Alexey ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug 2013-03-05 13:21 ` Alexey Kardashevskiy @ 2013-03-05 14:23 ` Michael S. Tsirkin 2013-03-05 22:57 ` Alexey Kardashevskiy 0 siblings, 1 reply; 9+ messages in thread From: Michael S. Tsirkin @ 2013-03-05 14:23 UTC (permalink / raw) To: Alexey Kardashevskiy; +Cc: rusty, qemu-devel@nongnu.org, David Gibson On Wed, Mar 06, 2013 at 12:21:47AM +1100, Alexey Kardashevskiy wrote: > On 05/03/13 23:56, Michael S. Tsirkin wrote: > >>The patch f56a12475ff1b8aa61210d08522c3c8aaf0e2648 "vhost: backend > >>masking support" breaks virtio-net + vhost=on on PPC64 platform. > >> > >>The problem command line is: > >>1) -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh,vhost=on \ > >>-device virtio-net-pci,netdev=tapnet,addr=0.0 \ > > > >I think the issue is irqfd in not supported on kvm ppc. > > How can I make sure this is the case? Some work has been done there > recently but midnight is quite late to figure this out :) Look in virtio_pci_set_guest_notifiers, what is the value of with_irqfd? bool with_irqfd = msix_enabled(&proxy->pci_dev) && kvm_msi_via_irqfd_enabled(); Also check what each of the values in the expression above is. > > >Could you please check this: > > > >+ /* If guest supports masking, set up irqfd now. > >+ * Otherwise, delay until unmasked in the frontend. > >+ */ > >+ if (proxy->vdev->guest_notifier_mask) { > >+ ret = kvm_virtio_pci_irqfd_use(proxy, queue_no, vector); > >+ if (ret < 0) { > >+ kvm_virtio_pci_vq_vector_release(proxy, vector); > >+ goto undo; > >+ } > >+ } > > > > > >Could you please add a printf before "undo" and check whether the > >error path above is triggered? > > > Checked, it is not triggered. > > > -- > Alexey I think I get it. Does the following help (probably not the right thing to do, but just for testing): Signed-off-by: Michael S. Tsirkin <mst@redhat.com> --- diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c index ba56ab2..c2a0c5a 100644 --- a/hw/virtio-pci.c +++ b/hw/virtio-pci.c @@ -800,6 +800,10 @@ static int virtio_pci_set_guest_notifiers(DeviceState *d, int nvqs, bool assign) } } + if (!with_irqfd && proxy->vdev->guest_notifier_mask) { + proxy->vdev->guest_notifier_mask(proxy->vdev, queue_no, !assign); + } + /* Must set vector notifier after guest notifier has been assigned */ if (with_irqfd && assign) { proxy->vector_irqfd = ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug 2013-03-05 14:23 ` Michael S. Tsirkin @ 2013-03-05 22:57 ` Alexey Kardashevskiy 2013-03-06 10:31 ` Michael S. Tsirkin 0 siblings, 1 reply; 9+ messages in thread From: Alexey Kardashevskiy @ 2013-03-05 22:57 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: rusty, qemu-devel@nongnu.org, David Gibson On 06/03/13 01:23, Michael S. Tsirkin wrote: > On Wed, Mar 06, 2013 at 12:21:47AM +1100, Alexey Kardashevskiy wrote: >> On 05/03/13 23:56, Michael S. Tsirkin wrote: >>>> The patch f56a12475ff1b8aa61210d08522c3c8aaf0e2648 "vhost: backend >>>> masking support" breaks virtio-net + vhost=on on PPC64 platform. >>>> >>>> The problem command line is: >>>> 1) -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh,vhost=on \ >>>> -device virtio-net-pci,netdev=tapnet,addr=0.0 \ >>> >>> I think the issue is irqfd in not supported on kvm ppc. >> >> How can I make sure this is the case? Some work has been done there >> recently but midnight is quite late to figure this out :) > > Look in virtio_pci_set_guest_notifiers, what is the > value of with_irqfd? > bool with_irqfd = msix_enabled(&proxy->pci_dev) && > kvm_msi_via_irqfd_enabled(); > > Also check what each of the values in the expression above is. Yes, ppc does not have irqfd as kvm_msi_via_irqfd_enabled() returned "false". >>> Could you please check this: >>> >>> + /* If guest supports masking, set up irqfd now. >>> + * Otherwise, delay until unmasked in the frontend. >>> + */ >>> + if (proxy->vdev->guest_notifier_mask) { >>> + ret = kvm_virtio_pci_irqfd_use(proxy, queue_no, vector); >>> + if (ret < 0) { >>> + kvm_virtio_pci_vq_vector_release(proxy, vector); >>> + goto undo; >>> + } >>> + } >>> >>> >>> Could you please add a printf before "undo" and check whether the >>> error path above is triggered? >> >> >> Checked, it is not triggered. >> >> >> -- >> Alexey > > I think I get it. > Does the following help (probably not the right thing to do, but just > for testing): It did not compile (no "queue_no") :) I changed it a bit and now vhost=on works fine: diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c index a869f53..df1e443 100644 --- a/hw/virtio-pci.c +++ b/hw/virtio-pci.c @@ -798,6 +798,10 @@ static int virtio_pci_set_guest_notifiers(DeviceState *d, int nvqs, bool assign) if (r < 0) { goto assign_error; } + + if (!with_irqfd && proxy->vdev->guest_notifier_mask) { + proxy->vdev->guest_notifier_mask(proxy->vdev, n, !assign); + } } /* Must set vector notifier after guest notifier has been assigned */ > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > --- > > diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c > index ba56ab2..c2a0c5a 100644 > --- a/hw/virtio-pci.c > +++ b/hw/virtio-pci.c > @@ -800,6 +800,10 @@ static int virtio_pci_set_guest_notifiers(DeviceState *d, int nvqs, bool assign) > } > } > > + if (!with_irqfd && proxy->vdev->guest_notifier_mask) { > + proxy->vdev->guest_notifier_mask(proxy->vdev, queue_no, !assign); > + } > + > /* Must set vector notifier after guest notifier has been assigned */ > if (with_irqfd && assign) { > proxy->vector_irqfd = > -- Alexey ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug 2013-03-05 22:57 ` Alexey Kardashevskiy @ 2013-03-06 10:31 ` Michael S. Tsirkin 2013-03-08 4:48 ` Alexey Kardashevskiy 0 siblings, 1 reply; 9+ messages in thread From: Michael S. Tsirkin @ 2013-03-06 10:31 UTC (permalink / raw) To: Alexey Kardashevskiy; +Cc: rusty, qemu-devel@nongnu.org, David Gibson On Wed, Mar 06, 2013 at 09:57:40AM +1100, Alexey Kardashevskiy wrote: > On 06/03/13 01:23, Michael S. Tsirkin wrote: > >On Wed, Mar 06, 2013 at 12:21:47AM +1100, Alexey Kardashevskiy wrote: > >>On 05/03/13 23:56, Michael S. Tsirkin wrote: > >>>>The patch f56a12475ff1b8aa61210d08522c3c8aaf0e2648 "vhost: backend > >>>>masking support" breaks virtio-net + vhost=on on PPC64 platform. > >>>> > >>>>The problem command line is: > >>>>1) -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh,vhost=on \ > >>>>-device virtio-net-pci,netdev=tapnet,addr=0.0 \ > >>> > >>>I think the issue is irqfd in not supported on kvm ppc. > >> > >>How can I make sure this is the case? Some work has been done there > >>recently but midnight is quite late to figure this out :) > > > >Look in virtio_pci_set_guest_notifiers, what is the > >value of with_irqfd? > > bool with_irqfd = msix_enabled(&proxy->pci_dev) && > > kvm_msi_via_irqfd_enabled(); > > > >Also check what each of the values in the expression above is. > > Yes, ppc does not have irqfd as kvm_msi_via_irqfd_enabled() returned "false". > > >>>Could you please check this: > >>> > >>>+ /* If guest supports masking, set up irqfd now. > >>>+ * Otherwise, delay until unmasked in the frontend. > >>>+ */ > >>>+ if (proxy->vdev->guest_notifier_mask) { > >>>+ ret = kvm_virtio_pci_irqfd_use(proxy, queue_no, vector); > >>>+ if (ret < 0) { > >>>+ kvm_virtio_pci_vq_vector_release(proxy, vector); > >>>+ goto undo; > >>>+ } > >>>+ } > >>> > >>> > >>>Could you please add a printf before "undo" and check whether the > >>>error path above is triggered? > >> > >> > >>Checked, it is not triggered. > >> > >> > >>-- > >>Alexey > > > >I think I get it. > >Does the following help (probably not the right thing to do, but just > >for testing): > > > It did not compile (no "queue_no") :) I changed it a bit and now > vhost=on works fine: > > diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c > index a869f53..df1e443 100644 > --- a/hw/virtio-pci.c > +++ b/hw/virtio-pci.c > @@ -798,6 +798,10 @@ static int > virtio_pci_set_guest_notifiers(DeviceState *d, int nvqs, bool > assign) > if (r < 0) { > goto assign_error; > } > + > + if (!with_irqfd && proxy->vdev->guest_notifier_mask) { > + proxy->vdev->guest_notifier_mask(proxy->vdev, n, !assign); > + } > } > > /* Must set vector notifier after guest notifier has been assigned */ > > I see, OK, the issue is that vhost now starts in a masked state and no one unmasks it. While the patch will work I think, it does not benefit from backend masking, the right thing to do is to add mask notifiers, like what the irqfd path does. Will look into this, thanks. -- MST ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug 2013-03-06 10:31 ` Michael S. Tsirkin @ 2013-03-08 4:48 ` Alexey Kardashevskiy 2013-03-10 9:24 ` Michael S. Tsirkin 0 siblings, 1 reply; 9+ messages in thread From: Alexey Kardashevskiy @ 2013-03-08 4:48 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: rusty, qemu-devel@nongnu.org, David Gibson Michael, Thanks for the fix. There was another question which was lost in the thread. I am testing virtio-net in two ways: Old -net interface: -net tap,ifname=tap0,script=qemu-ifup.sh \ -net nic,model=virtio,addr=0:0:0 (qemu) info network hub 0 \ virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ tap.0: index=0,type=tap,ifname=tap0,script=qemu-ifup.sh,downscript=/etc/qemu-ifdown New -netdev interface: -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh \ -device virtio-net-pci,netdev=tapnet,addr=0.0 (qemu) info network virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ tapnet: index=0,type=tap,ifname=tap0,script=qemu-ifup.sh,downscript=/etc/qemu-ifdown I get very different virtio0 device features and speed (70MB/s vs. 700MB/s). I guess somehow the "hub 0" is responsible but there is no way to avoid it. Is there any way to speed up the virtio-net using the old -net interface? On 06/03/13 21:31, Michael S. Tsirkin wrote: > On Wed, Mar 06, 2013 at 09:57:40AM +1100, Alexey Kardashevskiy wrote: >> On 06/03/13 01:23, Michael S. Tsirkin wrote: >>> On Wed, Mar 06, 2013 at 12:21:47AM +1100, Alexey Kardashevskiy wrote: >>>> On 05/03/13 23:56, Michael S. Tsirkin wrote: >>>>>> The patch f56a12475ff1b8aa61210d08522c3c8aaf0e2648 "vhost: backend >>>>>> masking support" breaks virtio-net + vhost=on on PPC64 platform. >>>>>> >>>>>> The problem command line is: >>>>>> 1) -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh,vhost=on \ >>>>>> -device virtio-net-pci,netdev=tapnet,addr=0.0 \ >>>>> >>>>> I think the issue is irqfd in not supported on kvm ppc. >>>> >>>> How can I make sure this is the case? Some work has been done there >>>> recently but midnight is quite late to figure this out :) >>> >>> Look in virtio_pci_set_guest_notifiers, what is the >>> value of with_irqfd? >>> bool with_irqfd = msix_enabled(&proxy->pci_dev) && >>> kvm_msi_via_irqfd_enabled(); >>> >>> Also check what each of the values in the expression above is. >> >> Yes, ppc does not have irqfd as kvm_msi_via_irqfd_enabled() returned "false". >> >>>>> Could you please check this: >>>>> >>>>> + /* If guest supports masking, set up irqfd now. >>>>> + * Otherwise, delay until unmasked in the frontend. >>>>> + */ >>>>> + if (proxy->vdev->guest_notifier_mask) { >>>>> + ret = kvm_virtio_pci_irqfd_use(proxy, queue_no, vector); >>>>> + if (ret < 0) { >>>>> + kvm_virtio_pci_vq_vector_release(proxy, vector); >>>>> + goto undo; >>>>> + } >>>>> + } >>>>> >>>>> >>>>> Could you please add a printf before "undo" and check whether the >>>>> error path above is triggered? >>>> >>>> >>>> Checked, it is not triggered. >>>> >>>> >>>> -- >>>> Alexey >>> >>> I think I get it. >>> Does the following help (probably not the right thing to do, but just >>> for testing): >> >> >> It did not compile (no "queue_no") :) I changed it a bit and now >> vhost=on works fine: >> >> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c >> index a869f53..df1e443 100644 >> --- a/hw/virtio-pci.c >> +++ b/hw/virtio-pci.c >> @@ -798,6 +798,10 @@ static int >> virtio_pci_set_guest_notifiers(DeviceState *d, int nvqs, bool >> assign) >> if (r < 0) { >> goto assign_error; >> } >> + >> + if (!with_irqfd && proxy->vdev->guest_notifier_mask) { >> + proxy->vdev->guest_notifier_mask(proxy->vdev, n, !assign); >> + } >> } >> >> /* Must set vector notifier after guest notifier has been assigned */ >> >> > > I see, OK, the issue is that vhost now starts in a masked state > and no one unmasks it. While the patch will work I think, > it does not benefit from backend masking, the right thing > to do is to add mask notifiers, like what the irqfd path does. > > Will look into this, thanks. > -- Alexey ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug 2013-03-08 4:48 ` Alexey Kardashevskiy @ 2013-03-10 9:24 ` Michael S. Tsirkin 2013-03-10 11:25 ` Alexey Kardashevskiy 0 siblings, 1 reply; 9+ messages in thread From: Michael S. Tsirkin @ 2013-03-10 9:24 UTC (permalink / raw) To: Alexey Kardashevskiy; +Cc: rusty, qemu-devel@nongnu.org, David Gibson On Fri, Mar 08, 2013 at 03:48:04PM +1100, Alexey Kardashevskiy wrote: > Michael, > > Thanks for the fix. > > There was another question which was lost in the thread. > > I am testing virtio-net in two ways: > > Old -net interface: > -net tap,ifname=tap0,script=qemu-ifup.sh \ > -net nic,model=virtio,addr=0:0:0 > > (qemu) info network > hub 0 > \ virtio-net-pci.0: > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 > \ tap.0: index=0,type=tap,ifname=tap0,script=qemu-ifup.sh,downscript=/etc/qemu-ifdown > > New -netdev interface: > -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh \ > -device virtio-net-pci,netdev=tapnet,addr=0.0 > > (qemu) info network > virtio-net-pci.0: > index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 > \ tapnet: index=0,type=tap,ifname=tap0,script=qemu-ifup.sh,downscript=/etc/qemu-ifdown > > > I get very different virtio0 device features and speed (70MB/s vs. > 700MB/s). I guess somehow the "hub 0" is responsible but there is no > way to avoid it. > > Is there any way to speed up the virtio-net using the old -net interface? Not at the moment. Why do you want to use it? > > On 06/03/13 21:31, Michael S. Tsirkin wrote: > >On Wed, Mar 06, 2013 at 09:57:40AM +1100, Alexey Kardashevskiy wrote: > >>On 06/03/13 01:23, Michael S. Tsirkin wrote: > >>>On Wed, Mar 06, 2013 at 12:21:47AM +1100, Alexey Kardashevskiy wrote: > >>>>On 05/03/13 23:56, Michael S. Tsirkin wrote: > >>>>>>The patch f56a12475ff1b8aa61210d08522c3c8aaf0e2648 "vhost: backend > >>>>>>masking support" breaks virtio-net + vhost=on on PPC64 platform. > >>>>>> > >>>>>>The problem command line is: > >>>>>>1) -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh,vhost=on \ > >>>>>>-device virtio-net-pci,netdev=tapnet,addr=0.0 \ > >>>>> > >>>>>I think the issue is irqfd in not supported on kvm ppc. > >>>> > >>>>How can I make sure this is the case? Some work has been done there > >>>>recently but midnight is quite late to figure this out :) > >>> > >>>Look in virtio_pci_set_guest_notifiers, what is the > >>>value of with_irqfd? > >>> bool with_irqfd = msix_enabled(&proxy->pci_dev) && > >>> kvm_msi_via_irqfd_enabled(); > >>> > >>>Also check what each of the values in the expression above is. > >> > >>Yes, ppc does not have irqfd as kvm_msi_via_irqfd_enabled() returned "false". > >> > >>>>>Could you please check this: > >>>>> > >>>>>+ /* If guest supports masking, set up irqfd now. > >>>>>+ * Otherwise, delay until unmasked in the frontend. > >>>>>+ */ > >>>>>+ if (proxy->vdev->guest_notifier_mask) { > >>>>>+ ret = kvm_virtio_pci_irqfd_use(proxy, queue_no, vector); > >>>>>+ if (ret < 0) { > >>>>>+ kvm_virtio_pci_vq_vector_release(proxy, vector); > >>>>>+ goto undo; > >>>>>+ } > >>>>>+ } > >>>>> > >>>>> > >>>>>Could you please add a printf before "undo" and check whether the > >>>>>error path above is triggered? > >>>> > >>>> > >>>>Checked, it is not triggered. > >>>> > >>>> > >>>>-- > >>>>Alexey > >>> > >>>I think I get it. > >>>Does the following help (probably not the right thing to do, but just > >>>for testing): > >> > >> > >>It did not compile (no "queue_no") :) I changed it a bit and now > >>vhost=on works fine: > >> > >>diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c > >>index a869f53..df1e443 100644 > >>--- a/hw/virtio-pci.c > >>+++ b/hw/virtio-pci.c > >>@@ -798,6 +798,10 @@ static int > >>virtio_pci_set_guest_notifiers(DeviceState *d, int nvqs, bool > >>assign) > >> if (r < 0) { > >> goto assign_error; > >> } > >>+ > >>+ if (!with_irqfd && proxy->vdev->guest_notifier_mask) { > >>+ proxy->vdev->guest_notifier_mask(proxy->vdev, n, !assign); > >>+ } > >> } > >> > >> /* Must set vector notifier after guest notifier has been assigned */ > >> > >> > > > >I see, OK, the issue is that vhost now starts in a masked state > >and no one unmasks it. While the patch will work I think, > >it does not benefit from backend masking, the right thing > >to do is to add mask notifiers, like what the irqfd path does. > > > >Will look into this, thanks. > > > > > -- > Alexey ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug 2013-03-10 9:24 ` Michael S. Tsirkin @ 2013-03-10 11:25 ` Alexey Kardashevskiy 0 siblings, 0 replies; 9+ messages in thread From: Alexey Kardashevskiy @ 2013-03-10 11:25 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: rusty, qemu-devel@nongnu.org, David Gibson On 10/03/13 20:24, Michael S. Tsirkin wrote: > On Fri, Mar 08, 2013 at 03:48:04PM +1100, Alexey Kardashevskiy wrote: >> Michael, >> >> Thanks for the fix. >> >> There was another question which was lost in the thread. >> >> I am testing virtio-net in two ways: >> >> Old -net interface: >> -net tap,ifname=tap0,script=qemu-ifup.sh \ >> -net nic,model=virtio,addr=0:0:0 >> >> (qemu) info network >> hub 0 >> \ virtio-net-pci.0: >> index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 >> \ tap.0: index=0,type=tap,ifname=tap0,script=qemu-ifup.sh,downscript=/etc/qemu-ifdown >> >> New -netdev interface: >> -netdev tap,id=tapnet,ifname=tap0,script=qemu-ifup.sh \ >> -device virtio-net-pci,netdev=tapnet,addr=0.0 >> >> (qemu) info network >> virtio-net-pci.0: >> index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 >> \ tapnet: index=0,type=tap,ifname=tap0,script=qemu-ifup.sh,downscript=/etc/qemu-ifdown >> >> >> I get very different virtio0 device features and speed (70MB/s vs. >> 700MB/s). I guess somehow the "hub 0" is responsible but there is no >> way to avoid it. >> >> Is there any way to speed up the virtio-net using the old -net interface? > > Not at the moment. Why do you want to use it? It is not like I really want it, I was just trying to understand (now it is more or less clear) why exactly "not" as the documentation is saying about -net and -netdev as synonyms while they are not. -- Alexey ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-03-10 11:24 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-05 6:55 [Qemu-devel] QEMU -netdev vhost=on + -device virtio-net-pci bug Alexey Kardashevskiy 2013-03-05 12:56 ` Michael S. Tsirkin 2013-03-05 13:21 ` Alexey Kardashevskiy 2013-03-05 14:23 ` Michael S. Tsirkin 2013-03-05 22:57 ` Alexey Kardashevskiy 2013-03-06 10:31 ` Michael S. Tsirkin 2013-03-08 4:48 ` Alexey Kardashevskiy 2013-03-10 9:24 ` Michael S. Tsirkin 2013-03-10 11:25 ` Alexey Kardashevskiy
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).