Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

[Jamie Lokier <jamie@shareable.org>]

Ian Molton wrote:
> One last and quite important point - where should the EGD protocol
> implementation go? really it needs to work as kind-of a line discipline,
> but AFAICT thats not supported? it would be a mistake to put rate
> limiting in the chardev layer and leave the EGD protocol implementation
> in the driver.

What do the other hypervisors supporting virtio-rng do?

Personally I'm failing to see why EGD support is needed in Qemu, as
none of the crypto services on my Linux machines seem to need it so
why should Qemu be special, but I acknowledge there might be some
obscure reason.

> TBH, for the sake of one very simple driver, and given that apparently
> no other users in qemu seem to want rate-limiting, *I( think that you
> are massively over-complicating matters right now. If more drivers need
> rate limiting, perhaps, but that doesnt seem to be the case.

Rate limiting both networking and serial ports may be a handy little
option sometimes.  Iirc, there are some guests which get confused when
data transfers are gazillions times faster than they expected, or
gazillions times more bursty in the case of networking.

> > We already have a virtual serial port implementation designed for 
> > exactly this kind of application.
> 
> Except that it doesn't speak to the kernels virtio-rng implementation.
> And that interface is not going to change just because you don't like
> it. (Unless you'd like to rewrite the kernels hwrng core? feel free! I'm
> sure it'd be appreciated - but if not, then don't complain)

Would it be much work to change the guest to use virtio-serial
instead?  Would it fit the problem or does virtio-rng need more
metadata than just a bytestream?

-- Jamie