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

[Blue Swirl <blauwirbel@gmail.com>]

On 4/20/10, Ian Molton <ian.molton@collabora.co.uk> wrote:
> Jamie Lokier wrote:
>
>  Hi :-)
>
>  > 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?
>
>  Um. support it? Im not sure what you mean there.
>
>  > 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.
>
>  I know seevral people who use egd based hardware on their hosts who want
>   virtio-rng support in their guests - it avoids having to route the data
>  via TCP or other long winded paths that are trivially vulverable to
>  attack both on the host and from the guests userspace. The hwrng core is
>  inherently very simple.
>
>  >> 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.
>
>  Perhaps, but I'm not a big user of those systems and as such Im not
>  really in a position to design a rate limiting algorithm thats going to
>  be really appropriate without spending a lot of time I dont have looking
>  at stuff I don't really care about.
>
>  I don't mind implementing trivial rate/burst limiting in the chardev
>  layer if thats whats wanted, but I have neither the time nor inclination
>  to write a thesis on the subject :-)
>
>  >  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.
>
>  Realistically, that kind of limiting might be best off in the device
>  drivers those systems use, which has more intimate knowledge of how the
>  virtual hardware should behave. Without extensive testing I just couldnt
>  answer that.
>
>  >>> 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?
>
>  If anything virtio-rng uses *less* info than the virtio-serial driver
>  (it has one stream, in one direction, only).
>
>  But the kernel already has a virtio-rng driver and it already works in a
>  particular way, which is already implemented in other hypervisors. I
>  didn't write the kernel driver, it is pre-existing. I suppose we could
>  ask the kernel devs if they'd like another virtio-based rng driver in
>  addition to the one already in use? but that seems perverse.
>
>  Why even bother with virtio at all if you're going to abstract
>  everything away behind a serial port? we could just modify all the guest
>  kernel virtio-block drivers to serialise all their metadata, then we
>  could use serial ports for that too!
>
>  Abstraction can be taken too far.
>
>  All MHO but I'm standing by what I said. If I can get a reasonable
>  consensus about rewriting the code so that we get all the features
>  needed for an enterprise level solution, namely
>
>  * Fault tolerance - socket reconnection support.
>  * EGD protocol support - because its what the users of this code (not me
>  as such, I don't actually use it at all myself) actually want
>  * virtio-rng support - because anything else is stupid and would involve
>  getting a second virtio-serial-rng driver into the kernel.
>
>  Then great.
>
>  IMHO, the socket reconnect patch and the SIZE parameter patch fix
>  obvious flaws in qemu and should be applied now, unless someone can come
>  up with a good reason why they shouldn't.
>
>  We can carry on debating the actual virtio-rng driver if thats whats
>  wanted, but I have stated my position. So far the only argument against
>  is "well I wouldn't choose to do it that way", which is hardly concrete
>  reasoning.
>
>  Please, please, can we get out of the bikeshed?

I would not call the discussions bikeshedding but architecture design
steering and project leadership.