Amos Kong <ak...@redhat.com> writes: > Bugzilla: https://bugs.launchpad.net/qemu/+bug/1253563 > > We have a requests queue to cache the random data, but the second > will come in when the first request is returned, so we always > only have one items in the queue. It effects the performance. > > This patch changes the IOthread to fill a fixed buffer with > random data from egd socket, request_entropy() will return > data to virtio queue if buffer has available data. > > (test with a fast source, disguised egd socket) > # cat /dev/urandom | nc -l localhost 8003 > # qemu .. -chardev socket,host=localhost,port=8003,id=chr0 \ > -object rng-egd,chardev=chr0,id=rng0,buf_size=1024 \ > -device virtio-rng-pci,rng=rng0 > > bytes kb/s > ------ ---- > 131072 -> 835 > 65536 -> 652 > 32768 -> 356 > 16384 -> 182 > 8192 -> 99 > 4096 -> 52 > 2048 -> 30 > 1024 -> 15 > 512 -> 8 > 256 -> 4 > 128 -> 3 > 64 -> 2
I'm not familiar with the rng-egd code, but perhaps my question has value anyway: could agressive reading ahead on a source of randomness cause trouble by depleting the source? Consider a server restarting a few dozen guests after reboot, where each guest's QEMU then tries to slurp in a couple of KiB of randomness. How does this behave?