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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/22/2012 07:31 AM, Daniel P. Berrange wrote:
> On Fri, Jun 22, 2012 at 07:22:51AM -0500, Anthony Liguori wrote:
>> 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.
>
> No it doesn't. As it stands currently, the only events that are
> rate limited, are those where there is no state information to
> loose. ie, the new event completely superceeds the old event
> without loosing any information.
>
>>                                                        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 RNG event will not be able to use the generic rate limiting
> since it has state associated with it. The rate limiting of the
> RNG QMP event will need to take account of this state, ie it
> will have to accumulate the byte count of any events dropped for
> rate limiting:
>
>    - Guest sends randomness request for 10 bytes
>    - QMP event gets sent for 10 bytes
>    - Guest sends randomness request for 4 bytes
>    - QMP is dropped
>    - Guest sends randomness request for 8 bytes
>    - QMP event gets sent for 12 bytes

BTW, in the current design, there's no way to tell *which* virtio-rng device 
needs entropy if you have multiple virtio-rng devices.

All of these problems are naturally solved using a protocol over a CharDriverState.

Regards,

Anthony Liguori

>
>
> Daniel