From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTSUD-0000FK-0w for qemu-devel@nongnu.org; Wed, 31 Oct 2012 03:13:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTSUA-00036t-9t for qemu-devel@nongnu.org; Wed, 31 Oct 2012 03:13:12 -0400 Received: from hall.aurel32.net ([88.191.126.93]:46591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTSUA-00035e-3O for qemu-devel@nongnu.org; Wed, 31 Oct 2012 03:13:10 -0400 Date: Wed, 31 Oct 2012 08:12:39 +0100 From: Aurelien Jarno Message-ID: <20121031071239.GA3855@ohm.aurel32.net> References: <1351638178-15056-1-git-send-email-aliguori@us.ibm.com> <50907DCB.50501@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <50907DCB.50501@zytor.com> Subject: Re: [Qemu-devel] [PATCH 0/8] add paravirtualization hwrng support (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "H. Peter Anvin" Cc: Amit Shah , Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org, Andreas Faerber On Tue, Oct 30, 2012 at 06:24:27PM -0700, H. Peter Anvin wrote: > On 10/30/2012 04:02 PM, Anthony Liguori wrote: > > > >My take away from all of the various discussions on what the Right Way to > >use virtio-rng is: > > > > 1) /dev/random should always be used as the entropy source (I've left it > > configurable though) > > > > 2) I think the Right Way to configure virtio-rng is to figure out what the > > available entropy is on the host, and then decide how to allocate that > > to each guest. As such, I've implemented rate limiting. > > > > I think QEMU is the right place to do this because this is a property of > > specific virtual machines. I can imagine a cloud provider wanting to > > guarantee a certain level of entropy for different classes of VMs. Even > > if rngd could be used to do this, configuring it differently for different > > guests would be cumbersome. > > > > rngd is not where this should happen, it should be in the > /dev/random implementation in the (host) kernel. That way it is > applicable to all types of clients, not just Qemu. > > > 3) `qemu -device virtio-rng-pci` will Just Work but risks exhausting host > > entropy. This means we can't make it the default for machines. But for > > most command line users, I think this is the behavior they want. > > It's a bit unfortunate, but I'm not going to push on that point. > > Given the migration issue I'll write up an implementation of a DRNG > (RDRAND/RDSEED) backend once this is upstream. If RDRAND is > disabled in the guest, but available in the host, this would be the > one to use. If RDRAND is available in the guest it should be used > directly if rngd is new enough, but since virtio-rng has been in the > kernel since 2008 there still might be some guests which could use > such an implementation without having been RDRAND-enabled. > That is also a good idea for emulation, and especially to provide non-x86 guests with entropy. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net