From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxKzp-0005lp-JW for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:03:45 -0400 Received: from [140.186.70.92] (port=52191 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxKzm-0005kY-NV for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:03:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxKzk-00036y-Um for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:03:42 -0400 Received: from mx20.gnu.org ([199.232.41.8]:40205) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxKzk-00036p-T5 for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:03:40 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NxKzj-0002S9-Qk for qemu-devel@nongnu.org; Thu, 01 Apr 2010 10:03:40 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG Date: Thu, 1 Apr 2010 14:03:36 +0000 References: <4BB2053C.6000701@collabora.co.uk> <201004011317.45269.paul@codesourcery.com> <20100401123036.GA1752@shareable.org> In-Reply-To: <20100401123036.GA1752@shareable.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004011503.36690.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Ian Molton , qemu-devel@nongnu.org, Gerd Hoffmann >> > This patch adds support for virtio-rng. Data is read from a >> > chardev and can be either raw entropy or received via the EGD protocol. >> >> I still don't get why you need this at all. It seems like >> virtio-serial would already provides everything you need. > >I guess when virtio-rng was first written, virtio-serial wasn't >flexible enough because it didn't support multiple devices That argument no longer holds. > and maybe virtio-rng is still needed to enforce the EGD protocol when that > is being used. Maybe, though the benefit of having this knowledge in wemu seems somewhat unclear. If we do want it then shouldn't be be implemented as a char device backend, rather than part of a specific serial port implementation? > > > + qemu_gettimeofday(&now); > > > > Using qemu_gettimeofday is almost certainly wrong, and you want to > > be using virtual time. Plus I'm not convinced this is the right > > place to enforce rate limiting. > > If it's for rate limiting how fast the guest can take entropy from the > host, to ensure the host's entropy cannot be exhausted by a single > greedy guest, then perhaps qemu_gettimeofday() is right here. I doubt > if virtual time is right, at least not by itself. gettimeofday can and does jump arbitrarily. Comparing returned values is almost always wrong. Paul