Re: [libvirt] [REPOST PATCH v2 6/9] qemu: Add support for parsing iotune group setting
[...]
>> Also, once you do what I'm suggesting, the crash from 6/9
will be resolved,
>> however I still would like to see the @reply structure in
>> qemuDomainGetBlockIoTune initialized properly on the stack.
>
> Weird how that crash happens for you, but not me especially since you
> show 20 nparams which would seem to imply you're getting something back
> from qemu. Even though it's not set by libvirt, qemu does default to
> something (the id/alias for the object - in my case "drive-virtio-disk0"
> for my qemu 2.6.2). What do you get from a command:
>
> virsh qemu-monitor-command $domain
'{"execute":"query-block"}'
>
> ?
>
The returned JSON doesn't indicate any default on my qemu 2.6.0:
[...]
Ahhh... Right a domain without iotune adjustments... I think I checked
that at one time, but that was before I changed my mind in the
implementation from having "group" be some number to allowing a string
for group. With the number implementation I was just prepending some
constant string. So I guess I had it in my mind that I had already
tested that non iotune path.
What I did was just to start a domain that had no block iotuning
turned on
whatsoever and when I saw the code I was like, wait, I need to try that as it
looked suspicious at first glance (since at that moment I'd already known about
the missing initialization) so I tried it and it crashed.
> In any case, I'll add a memset(&reply, 0, sizeof(reply)) in the qemu
Yeah, that would do, sure, but is there a problem with a plain static
initialization at the function entry point? I mean that's where we (most of the
time) put all of our initializations and also where everyone would actually
expect such an assignment to take place...
Erik
OK, I'll just change the definition:
virDomainBlockIoTuneInfo reply = {0};
John