diff options
Diffstat (limited to 'results/classifier/118/all/1286253')
| -rw-r--r-- | results/classifier/118/all/1286253 | 135 |
1 files changed, 135 insertions, 0 deletions
diff --git a/results/classifier/118/all/1286253 b/results/classifier/118/all/1286253 new file mode 100644 index 00000000..89fe36d0 --- /dev/null +++ b/results/classifier/118/all/1286253 @@ -0,0 +1,135 @@ +permissions: 0.986 +performance: 0.974 +device: 0.969 +peripherals: 0.969 +graphic: 0.967 +debug: 0.966 +ppc: 0.962 +semantic: 0.960 +hypervisor: 0.959 +mistranslation: 0.958 +TCG: 0.957 +risc-v: 0.956 +x86: 0.956 +register: 0.955 +user-level: 0.954 +files: 0.953 +architecture: 0.951 +assembly: 0.949 +PID: 0.949 +virtual: 0.946 +KVM: 0.945 +vnc: 0.943 +network: 0.938 +arm: 0.936 +kernel: 0.927 +VMM: 0.925 +boot: 0.913 +socket: 0.913 +i386: 0.848 + +virtio-net acceleration features not set when plugged into backend dynamically + +When using indpendent transport and backend in this case virtio-net-device transport, none of the acceleration features are set after guest probes the transport the backend is plugged into. For virtio-net this leads to low throughput/performance. This holds true for virtio-mmio, PCI transports and most likely for others as well (CCW, S390) and other backends + +Command to run: +./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \ + -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \ + -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \ + -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58" + +For x86 same virtio command for network. + +On Fri, Feb 28, 2014 at 05:40:19PM -0000, Mario Smarduch wrote: +> When using indpendent transport and backend in this case virtio-net- +> device transport, none of the acceleration features are set after guest +> probes the transport the backend is plugged into. For virtio-net this +> leads to low throughput/performance. This holds true for virtio-mmio, +> PCI transports and most likely for others as well (CCW, S390) and other +> backends +> +> Command to run: +> ./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \ +> -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \ +> -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \ +> -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58" +> +> For x86 same virtio command for network. + +Can you explain in more detail? + +The command-line looks sane. The virtio-net-device instance should +figure out the tap supports offloads. + +Did you try adding a printf to virtio_net_get_features() to see why the +offload features are not being detected? + +Stefan + + +I don't have an x86 setup handy, but looking through the code 'virtio-net-pci' will +work but not 'virtio-net-device'. My understanding was the goal is for any +backend to plug into any transport on any platform. I'll try an x86 test with +'virtio-net-device' option and see what happens. + +Yes I did check the options on host after device is plugged and guest after features +are probed, only the MAC feature is set. + +Thanks, +- Mario + +-----Original Message----- +From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Michael S. Tsirkin +Sent: Monday, March 03, 2014 4:49 AM +To: Stefan Hajnoczi +Cc: Bug 1286253; <email address hidden> +Subject: Re: [Qemu-devel] [Bug 1286253] [NEW] virtio-net acceleration features not set when plugged into backend dynamically + +On Mon, Mar 03, 2014 at 01:37:46PM +0100, Stefan Hajnoczi wrote: +> On Fri, Feb 28, 2014 at 05:40:19PM -0000, Mario Smarduch wrote: +> > When using indpendent transport and backend in this case virtio-net- +> > device transport, none of the acceleration features are set after +> > guest probes the transport the backend is plugged into. For +> > virtio-net this leads to low throughput/performance. This holds +> > true for virtio-mmio, PCI transports and most likely for others as +> > well (CCW, S390) and other backends +> > +> > Command to run: +> > ./qemu-system-arm -enable-kvm -smp 2 -kernel zImage -dtb ./guest-a15.dtb -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \ +> > -append "root=/dev/vda rw console=ttyAMA0 rootwait" -drive if=none,file=/mnt/gauss.root,id=vm1 \ +> > -device virtio-blk-device,drive=vm1 -netdev type=tap,id=net0,ifname=tap0 \ +> > -device virtio-net-device,netdev=net0,mac="52:54:00:12:34:58" +> > +> > For x86 same virtio command for network. +> +> Can you explain in more detail? +> +> The command-line looks sane. The virtio-net-device instance should +> figure out the tap supports offloads. +> +> Did you try adding a printf to virtio_net_get_features() to see why +> the offload features are not being detected? +> +> Stefan + +IIUC mmio does not set any feature bits, so you get the fallback behaviour: + +$ git grep DEFINE_VIRTIO_NET_FEATURES +hw/s390x/s390-virtio-bus.c: DEFINE_VIRTIO_NET_FEATURES(VirtIOS390Device, host_featur +hw/s390x/virtio-ccw.c: DEFINE_VIRTIO_NET_FEATURES(VirtioCcwDevice, host_features[0]) +hw/virtio/virtio-pci.c: DEFINE_VIRTIO_NET_FEATURES(VirtIOPCIProxy, host_features), +include/hw/virtio/virtio-net.h:#define DEFINE_VIRTIO_NET_FEATURES(_state, _field) \ + +But it should work for pci, and certainly does for x86. + + +-- +MST + + + + +Which version of QEMU did you use here? Can you still reproduce this problem with the latest version of QEMU (currently v2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + |