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 - 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. Probably want to include the ENTROPY_NEEDED event in my patch which adds rate limiting to guest initiated events. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|