From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbV5i-0000EH-SG for qemu-devel@nongnu.org; Mon, 04 Jun 2012 07:05:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbV5g-0003nz-WD for qemu-devel@nongnu.org; Mon, 04 Jun 2012 07:04:54 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:49104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbV5g-0003nd-QZ for qemu-devel@nongnu.org; Mon, 04 Jun 2012 07:04:52 -0400 Received: by dadv2 with SMTP id v2so6167271dad.4 for ; Mon, 04 Jun 2012 04:04:51 -0700 (PDT) Message-ID: <4FCC9649.3050302@codemonkey.ws> Date: Mon, 04 Jun 2012 19:04:41 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <4FBFE4F5.7010408@codemonkey.ws> <20120525202018.GA21590@amit.redhat.com> In-Reply-To: <20120525202018.GA21590@amit.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Amit Shah Cc: qemu list On 05/26/2012 04:20 AM, Amit Shah wrote: > On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote: >> On 05/25/2012 02:32 PM, 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}} >> >> I don't understand the point of this event. Can't a management app >> just create a socket and then it can see all the requests the guest >> makes? > > How? With the chardev, it can only keep feeding data, and that data > will be consumed when chr_can_read() returns> 0. And even then the > mgmt app has no idea how much data was asked for, and how much was > consumed. Okay, then the right approach is to use a message protocol where QEMU asks for a certain amount of data and then the daemon sends it back. I think this is pretty much why the egd protocol exists, no? Why not just implement egd protocol support? Once we introduce a protocol of any form (even raw), we have to support it forever so let's not do it carelessly. Regards, Anthony Liguori > > Amit > >