From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYw4d-0008Je-Rv for qemu-devel@nongnu.org; Mon, 28 May 2012 05:17:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SYw4c-0007Cf-1Z for qemu-devel@nongnu.org; Mon, 28 May 2012 05:17:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SYw4b-0007CZ-PQ for qemu-devel@nongnu.org; Mon, 28 May 2012 05:17:09 -0400 Date: Mon, 28 May 2012 14:47:02 +0530 From: Amit Shah Message-ID: <20120528091702.GD27897@amit.redhat.com> References: <20120528083357.GB19909@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120528083357.GB19909@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu list , Anthony Liguori On (Mon) 28 May 2012 [09:33:57], Daniel P. Berrange wrote: > On Sat, May 26, 2012 at 01:02:49AM +0530, Amit Shah wrote: > > The Linux kernel already has a virtio-rng driver, this is the device > > implementation. > > > > When the guest asks for entropy from the virtio hwrng, it puts a buffer > > in the vq. We then put entropy into that buffer, and push it back to > > the guest. > > > > The chardev connected to this device is fed the data to be sent to the > > guest. > > > > Invocation is simple: > > > > $ qemu ... -device virtio-rng-pci,chardev=foo > > > > In the guest, we see > > > > $ cat /sys/devices/virtual/misc/hw_random/rng_available > > virtio > > > > $ cat /sys/devices/virtual/misc/hw_random/rng_current > > virtio > > > > # cat /dev/hwrng > > > > Simply feeding /dev/urandom from the host to the chardev is sufficient: > > > > $ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \ > > -device virtio-rng,chardev=foo > > > > $ nc -U /tmp/foo < /dev/urandom > > ACK to this ARGV design from a libvirt POV. > > > A QMP event is sent for interested apps to monitor activity and send the > > appropriate number of bytes that get asked by the guest: > > > > {"timestamp": {"seconds": 1337966878, "microseconds": 517009}, \ > > "event": "ENTROPY_NEEDED", "data": {"bytes": 64}} > > IIUC, there are three ways mgmt apps can use the RNG with the > chardev > > - Wire it up to a source that just blindly provides all the > entropy QEMU desires (as you /dev/urandom example above) > > - Feed in a fixed amount of entropy every minute, regardless > of how much QEMU desires This option currently won't do anything -- i.e. till the guest sends across a buffer to be filled in, nothing will go to the guest, and the data will just be buffered in the chardev layer till such a buffer comes along. It can be debatable on feeding entropy by pushing every particular timeout, or just providing the freshest on-demand. Advantage could be we have more random bits, disadvantage is this could be throttled as the host went out of enough entropy. > - Feed in entropy on demand, in response to the ENTROPY_NEEDED > event notification (possibly throttling) > > These options sounds like they should cover all reasonable needs, > so gets my vote. Great! > Probably want to include the ENTROPY_NEEDED > event in my patch which adds rate limiting to guest initiated > events. Yes, just depends in which order the patches go in. Thanks, Amit