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