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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
|
failed to set sndbuf on VMs network interface
I am trying to set "sndbuf" for a VMs network device to "0".
I inserted to my XML file:
<tune>
<sndbuf>0</sndbuf>
</tune>
The XML file validates, but I am not able to start the virtual machine.
# virsh edit vm3
<domain type='kvm'>
<name>vm3</name>
<uuid><HIDDEN></uuid>
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
<vcpu placement='static'>1</vcpu>
<os>
<type arch='x86_64' machine='pc-1.2'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='<HIDDEN>'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>
<controller type='usb' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
</controller>
<interface type='bridge'>
<mac address='<HIDDEN>'/>
<source bridge='br2'/>
<model type='virtio'/>
<tune>
<sndbuf>0</sndbuf>
</tune>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes'/>
<sound model='ich6'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</sound>
<video>
<model type='cirrus' vram='9216' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</memballoon>
</devices>
</domain>
Domain vm3 XML configuration edited.
# LANG=en_US.utf-8 virsh start vm3
error: Failed to start domain vm3
error: internal error Process exited while reading console log output: char device redirected to /dev/pts/4
Thanks for reporting this bug. This is a reqression in qemu-kvm since precise. In precise, the following works fine (meaning, kvm starts up - no idea if it does what it should):
kvm -vnc :1 -cdrom raring-mini-amd64.iso -hda raring.img -net nic,model=virtio -net tap,script=no,downscript=no,ifname=tap0,sndbuf=0
In raring (and presumably quantal) it gives a segfault
Latest upstream qemu.git still reproduces this, so marking it as affecting QEMU.
On Mon, Nov 26, 2012 at 1:43 PM, Andreas Färber <email address hidden> wrote:
> Am 26.11.2012 13:10, schrieb Stefan Hajnoczi:
>> visit_type_size() requires either visitor->type_size() or
>> visitor_uint64() to be implemented, otherwise a NULL function pointer is
>> invoked.
>>
>> It is possible to trigger this crash as follows:
>>
>> $ qemu-system-x86_64 -netdev tap,sndbuf=0,id=netdev0 \
>> -device virtio-blk-pci,netdev=netdev0
>>
>> The 'sndbuf' option has type "size".
>>
>> Signed-off-by: Stefan Hajnoczi <email address hidden>
>> ---
>> This patch ensures that -netdev tap,sndbuf=X works in QEMU 1.3.
>
> Reviewed-by: Andreas Färber <email address hidden>
>
> Did you check whether any other types were unhandled?
The visitors do not handle all types. Only the opts visitor and now
the dealloc visitor handle ->type_size().
This will not cause a problem yet because only the netdev options
include fields with the 'size' type. That code path is now covered.
In the longer term we should clean up the int, number, uint64, size
type proliferation and handle them consistently.
> Should a comment be added somewhere along the lines of "If you add a
> hook here you also need to implement one there" to avoid such
> inconsistency for the future?
There is no single point like register_visitor() where we could check
that callbacks are set up. That would have been a nice way to prevent
incomplete visitors.
The issue is that qapi/qapi-visit-core.h says type_uint64 and
type_size may be NULL, but it documents that visit_type_size() falls
back to type_uint64() if type_size() is NULL. The case we hit was
that type_uint64() is also NULL. Should it fall back to type_int()
(int64_t)?
Stefan
On Mon, Nov 26, 2012 at 02:22:58PM +0100, Stefan Hajnoczi wrote:
> On Mon, Nov 26, 2012 at 1:43 PM, Andreas Färber <email address hidden> wrote:
> > Am 26.11.2012 13:10, schrieb Stefan Hajnoczi:
> >> visit_type_size() requires either visitor->type_size() or
> >> visitor_uint64() to be implemented, otherwise a NULL function pointer is
> >> invoked.
> >>
> >> It is possible to trigger this crash as follows:
> >>
> >> $ qemu-system-x86_64 -netdev tap,sndbuf=0,id=netdev0 \
> >> -device virtio-blk-pci,netdev=netdev0
> >>
> >> The 'sndbuf' option has type "size".
> >>
> >> Signed-off-by: Stefan Hajnoczi <email address hidden>
> >> ---
> >> This patch ensures that -netdev tap,sndbuf=X works in QEMU 1.3.
> >
> > Reviewed-by: Andreas Färber <email address hidden>
> >
> > Did you check whether any other types were unhandled?
>
> The visitors do not handle all types. Only the opts visitor and now
> the dealloc visitor handle ->type_size().
>
> This will not cause a problem yet because only the netdev options
> include fields with the 'size' type. That code path is now covered.
>
> In the longer term we should clean up the int, number, uint64, size
> type proliferation and handle them consistently.
Dealloc visitor is somewhat of a special case, as it only cares about
the underlying C type and not about the visitor-specific representation.
In the case of generated types like these, it only needs to match the
type that QAPI generates (uint64_t in the case of type_size).
For input/output visitors, new types should either have a compatible
fallback, or abort if there's no compatible fallback and we attempt to
use a visitor that doesn't support the type. AFAIK we don't have one
that falls into the latter category atm (there is one in the QIDL series
for native C arrays, which has no generic fallback and will abort in
cases where we use a visitor that doesn't implement that type
explicitly).
Dealloc shouldn't use compatibility fallbacks though, which is probably
something we need to clean up. It should have explicit implementations
for all types we introduce, and those implementations should match the
type use for QAPI-generated types.
>
> > Should a comment be added somewhere along the lines of "If you add a
> > hook here you also need to implement one there" to avoid such
> > inconsistency for the future?
>
> There is no single point like register_visitor() where we could check
> that callbacks are set up. That would have been a nice way to prevent
> incomplete visitors.
>
> The issue is that qapi/qapi-visit-core.h says type_uint64 and
> type_size may be NULL, but it documents that visit_type_size() falls
> back to type_uint64() if type_size() is NULL. The case we hit was
> that type_uint64() is also NULL. Should it fall back to type_int()
> (int64_t)?
I hit this issue implementing a test case for QIDL that introduces
the usage of type_size() for QmpOutputVisitor. The problem is that it
references ->type_uint64() directly instead of using visit_type_uint64()
which has the fallback handling (->type_int()) for visitors that don't
have a specific implementation for type_uint64.
I have a patch in the QIDL series that does this, and this would also fix the
issue you're hitting with the dealloc visitor, but as noted above I
think relying on fallbacks for the dealloc visitor is the wrong
approach, so I think we should treat these as 2 seperate issues and take
your patch for 1.3. The error case I hit isn't reachable in 1.3 atm so I
think that should be sufficient for now.
>
> Stefan
>
On Mon, Nov 26, 2012 at 01:10:12PM +0100, Stefan Hajnoczi wrote:
> visit_type_size() requires either visitor->type_size() or
> visitor_uint64() to be implemented, otherwise a NULL function pointer is
> invoked.
>
> It is possible to trigger this crash as follows:
>
> $ qemu-system-x86_64 -netdev tap,sndbuf=0,id=netdev0 \
> -device virtio-blk-pci,netdev=netdev0
>
> The 'sndbuf' option has type "size".
>
> Signed-off-by: Stefan Hajnoczi <email address hidden>
Reviewed-by: Michael Roth <email address hidden>
> ---
> This patch ensures that -netdev tap,sndbuf=X works in QEMU 1.3.
>
> qapi/qapi-dealloc-visitor.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/qapi/qapi-dealloc-visitor.c b/qapi/qapi-dealloc-visitor.c
> index a154523..a07b171 100644
> --- a/qapi/qapi-dealloc-visitor.c
> +++ b/qapi/qapi-dealloc-visitor.c
> @@ -132,6 +132,11 @@ static void qapi_dealloc_type_number(Visitor *v, double *obj, const char *name,
> {
> }
>
> +static void qapi_dealloc_type_size(Visitor *v, size_t *obj, const char *name,
> + Error **errp)
> +{
> +}
> +
> static void qapi_dealloc_type_enum(Visitor *v, int *obj, const char *strings[],
> const char *kind, const char *name,
> Error **errp)
> @@ -164,6 +169,7 @@ QapiDeallocVisitor *qapi_dealloc_visitor_new(void)
> v->visitor.type_bool = qapi_dealloc_type_bool;
> v->visitor.type_str = qapi_dealloc_type_str;
> v->visitor.type_number = qapi_dealloc_type_number;
> + v->visitor.type_size = qapi_dealloc_type_size;
>
> QTAILQ_INIT(&v->stack);
>
> --
> 1.8.0
>
>
Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.]
[Expired for QEMU because there has been no activity for 60 days.]
|