On (Tue) 17 Dec 2013 [08:47:34], Markus Armbruster wrote:
> 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?
It is a problem and we surely don't want such a problem. So far, it
looks like we need to test this differently. I'm not at all sure
these numbers will be meaningful once we get a proper test going.
Amit
