From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbqTM-0002V1-6U for qemu-devel@nongnu.org; Tue, 05 Jun 2012 05:54:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbqTJ-0003vn-RN for qemu-devel@nongnu.org; Tue, 05 Jun 2012 05:54:43 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:57632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbqTJ-0003ve-Hz for qemu-devel@nongnu.org; Tue, 05 Jun 2012 05:54:41 -0400 Received: by dadv2 with SMTP id v2so7653637dad.4 for ; Tue, 05 Jun 2012 02:54:39 -0700 (PDT) Message-ID: <4FCDD756.7070200@codemonkey.ws> Date: Tue, 05 Jun 2012 17:54:30 +0800 From: Anthony Liguori MIME-Version: 1.0 References: <4FBFE4F5.7010408@codemonkey.ws> <20120525202018.GA21590@amit.redhat.com> <4FCC9649.3050302@codemonkey.ws> <20120605094139.GF18323@amit.redhat.com> In-Reply-To: <20120605094139.GF18323@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 06/05/2012 05:41 PM, Amit Shah wrote: > On (Mon) 04 Jun 2012 [19:04:41], Anthony Liguori wrote: >> 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. > > Why is a message protocol necessary? And a daemon isn't necessary, > too. > >> I think this is pretty much why the egd protocol exists, no? Why >> not just implement egd protocol support? > > Perhaps I'm not getting what you're saying. > > What we have here, via the event, is to tell the mgmt app that the > guest has need for entropy. *out-of-band* Why not just make that all in-band? I understand you're trying to accomodate a use-case of feeding /dev/random to QEMU. I don't think this is a necessary use-case though because I don't think it's correct. You need to use an entropy daemon of some sort to make sure entropy is being distributed in a fair fashion. > The guest also tells us exactly how many > bytes it needs. We're just passing on that info to the mgmt app, if > it needs it. > > In any case, any data pushed down the chardev will be consumed by the > device, and sent to the guest when the guest puts a buf in the vq. > >> Once we introduce a protocol of any form (even raw), we have to >> support it forever so let's not do it carelessly. > > There's no need for a protocol at all here. The event *is* a protocol. That's the point. Here's what you're making a management app do: 1) Open a socket 2) Feed socket fd to QEMU 3) Listen for event on QMP for entropy request 4) Read entropy based on (3) from /dev/random 5) Send entropy to socket to QEMU This is pretty silly when you can just do: 1) Open a socket 2) Listen for entropy request 3) Read entry based on (2) from /dev/random 4) Respond to (2) with (3) And there's already a tool and protocol for exactly the above--egd. There's simply no good reason to involve QMP here. Regards, Anthony Liguori Can you skim through the > code and point out where you think we're disagreeing? > > Amit