From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4JnC-0007sc-Vw for qemu-devel@nongnu.org; Tue, 20 Apr 2010 16:11:35 -0400 Received: from [140.186.70.92] (port=57402 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4Jn8-0007sE-Ok for qemu-devel@nongnu.org; Tue, 20 Apr 2010 16:11:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4Jn2-0004oL-Hx for qemu-devel@nongnu.org; Tue, 20 Apr 2010 16:11:28 -0400 Received: from mail-pz0-f204.google.com ([209.85.222.204]:49505) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Jn2-0004o2-8W for qemu-devel@nongnu.org; Tue, 20 Apr 2010 16:11:24 -0400 Received: by pzk42 with SMTP id 42so4463451pzk.4 for ; Tue, 20 Apr 2010 13:11:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4BCE061B.2030506@collabora.co.uk> References: <4BB2053C.6000701@collabora.co.uk> <201004031606.26893.paul@codesourcery.com> <4BC482A6.4040504@collabora.co.uk> <201004131632.25820.paul@codesourcery.com> <4BCDC51F.2030205@collabora.co.uk> <20100420161302.GA11723@shareable.org> <4BCE061B.2030506@collabora.co.uk> Date: Tue, 20 Apr 2010 23:11:21 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG From: Blue Swirl Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Molton Cc: qemu-devel@nongnu.org, Gerd Hoffmann , Paul Brook On 4/20/10, Ian Molton 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.