On 4/20/10, Ian Molton <ian.mol...@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.
