From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4G4Y-0007r3-L4 for qemu-devel@nongnu.org; Tue, 20 Apr 2010 12:13:14 -0400 Received: from [140.186.70.92] (port=42723 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4G4U-0007nC-GX for qemu-devel@nongnu.org; Tue, 20 Apr 2010 12:13:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4G4S-00009Q-Lx for qemu-devel@nongnu.org; Tue, 20 Apr 2010 12:13:10 -0400 Received: from mail2.shareable.org ([80.68.89.115]:43172) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4G4S-00009B-HG for qemu-devel@nongnu.org; Tue, 20 Apr 2010 12:13:08 -0400 Date: Tue, 20 Apr 2010 17:13:02 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG Message-ID: <20100420161302.GA11723@shareable.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCDC51F.2030205@collabora.co.uk> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Molton Cc: Gerd Hoffmann , Paul Brook , qemu-devel@nongnu.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