Re: [Qemu-devel] [PATCH v3 1/1] virtio-rng: hardware random number generator device

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/22/2012 07:12 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@codemonkey.ws>  writes:
>> Nack.
>>
>> Use a protocol.  This is not what QMP events are designed for!
>>
>> No human is going to launch nc to a unix domain socket to launch QEMU.
>> That's a silly use-case to design for.
>
> To be honest, I'm a bit surprised to see working code that got an ACK
> from the guys with the problem it solves rejected out of hand over
> something that feels like artistic license to me.

This is an ABI!  We have to support it for the rest of time.  Everything else is 
a detail that is fixable but ABIs need to not suck from the beginning.

And using a QMP event here is sucks.  It disappoints me that this is even 
something I need to explain.

QMP events occur over a single socket.  If you trigger them from guest initiated 
activities (that have no intrinsic rate limit), you run into a situation where 
the guest could flood the management tool and/or queue infinite amounts of 
memory (because events have to be queued before they're sent).  So we have rate 
limiting for QMP events.

That means QMP events (like this one) are unreliable.  But since QMP events 
aren't acked, there's no way for the management tool to know whether a QMP event 
was dropped or not.  So you can run into the following scenario:

- Guest sends randomness request for 10 bytes
- QMP event gets sent for 10 bytes
- Guest sends randomness request for 4 bytes
- QMP is dropped

Now what happens?  With the current virtio-rng, nothing.  It gets stuck in 
read() for ever.  Now what do we do?

The solution is simple--don't use a shared resource for virtio-rng events such 
that you don't need to worry about rate limiting or event queueing.  You process 
one request, then one piece of data, all over the same socket.

Regards,

Anthony Liguori