From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Si1gr-0005W2-28 for qemu-devel@nongnu.org; Fri, 22 Jun 2012 07:06:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Si1gm-00064l-4i for qemu-devel@nongnu.org; Fri, 22 Jun 2012 07:06:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Si1gl-00064G-TR for qemu-devel@nongnu.org; Fri, 22 Jun 2012 07:06:08 -0400 Date: Fri, 22 Jun 2012 16:36:01 +0530 From: Amit Shah Message-ID: <20120622110601.GB24801@amit.redhat.com> References: <4FE240B2.4070907@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE240B2.4070907@codemonkey.ws> Subject: Re: [Qemu-devel] [PATCH v3 1/1] virtio-rng: hardware random number generator device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu list On (Wed) 20 Jun 2012 [16:29:22], Anthony Liguori wrote: > On 06/20/2012 01:59 AM, 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 > > > >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}} > > Nack. > > Use a protocol. How does one write a program on Linux to get random numbers? He uses /dev/random, of course. What's the protocol? It's just a stream of bytes. What is egd? From their website: A userspace substitute for /dev/random, written in perl. It was written for systems that do not have /dev/random. How does a userspace program give out information to those who ask for it? It depends on how it gets designed. These people decided to create some protocol. Is there a specification on any protocol for consuming random numbers? No, there isn't. If anyone is so inclined to use a "protocol" for something as simple as a stream of bytes, he/she is most welcome to write a simple little script that reads the "protocol" and gives the output to a qemu chardev. QEMU has no business whatsoever to be bound to protocols which have no significance nor specification nor wide-spread usage. It's just surprising that we're debating this! So what are you really thinking about here? There's no magic that needs to be done to consume random numbers. > This is not what QMP events are designed for! Anthony, please read my responses to the last thread. The QMP event is *not* mandatory to be used. > No human is going to launch nc to a unix domain socket to launch > QEMU. That's a silly use-case to design for. You're right in two ways: 1) libvirt is going to be the main tool launching qemu, and libvirt is happy with the design. 2) humans launching qemu by hand are not going to have much use for a hwrng in the guest. If they do, however, the easiest (and, indeed, the best) way is the way I show above. Amit