1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
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.]
|