Re: proposal: deprecate -readconfig/-writeconfig

[Markus Armbruster]

Daniel P. Berrangé <address@hidden> writes:

> On Thu, May 14, 2020 at 05:51:02PM +0200, Paolo Bonzini wrote:
>> On 14/05/20 17:34, Daniel P. Berrangé wrote:
>> > Yeah, the key thing is that you really want to be able to provide the
>> > whole initial config in one go as an atomic action. I don't want to
>> > issue 100 individual QMP commands to load each initial device.
>> 
>> Why?  I think if we do something like the qemu-vm-$TARGET that you
>> propose below, there's absolutely no difference between the two.
>
> Ok, I should clarify. I don't want to do 100 individual serialized
> round-trip request+reply, as that'd create latency on startup.
> 100 pipelined/parallelized request+reply would be ok, as you'll
> not have the synchronization delay for each command.
>
> Today the biggest cause of slow startup in libvirt, is issuing
> something like 100+ serialized QMP calls to check status of
> individual CPUID features. Possibly this is already just a libvirt
> bug we can could just stuff all 100 qom-get queries down the pipe
> in one go and have 1 wait for replies to arrive.

Hundreds of serialized QMP roundtrips are certainly bad.

Sending hundreds of QMP commands before reading any QMP output would
also be bad: it relies on QEMU to buffer the output.  It does, but
unlimited buffering is bad, and you shouldn't rely on it to stay.

Instead, send your input as fast as QEMU accepts it (it *will* stop
reading if you send input faster than it can process it), and also
receive output as fast as you can, until you got it all.

[...]