On Tue, Oct 30, 2012 at 06:24:27PM -0700, H. Peter Anvin wrote: > On 10/30/2012 04:02 PM, Anthony Liguori wrote: > > > >My take away from all of the various discussions on what the Right Way to > >use virtio-rng is: > > > > 1) /dev/random should always be used as the entropy source (I've left it > > configurable though) > > > > 2) I think the Right Way to configure virtio-rng is to figure out what the > > available entropy is on the host, and then decide how to allocate that > > to each guest. As such, I've implemented rate limiting. > > > > I think QEMU is the right place to do this because this is a property of > > specific virtual machines. I can imagine a cloud provider wanting to > > guarantee a certain level of entropy for different classes of VMs. Even > > if rngd could be used to do this, configuring it differently for > > different > > guests would be cumbersome. > > > > rngd is not where this should happen, it should be in the > /dev/random implementation in the (host) kernel. That way it is > applicable to all types of clients, not just Qemu. > > > 3) `qemu -device virtio-rng-pci` will Just Work but risks exhausting host > > entropy. This means we can't make it the default for machines. But for > > most command line users, I think this is the behavior they want. > > It's a bit unfortunate, but I'm not going to push on that point. > > Given the migration issue I'll write up an implementation of a DRNG > (RDRAND/RDSEED) backend once this is upstream. If RDRAND is > disabled in the guest, but available in the host, this would be the > one to use. If RDRAND is available in the guest it should be used > directly if rngd is new enough, but since virtio-rng has been in the > kernel since 2008 there still might be some guests which could use > such an implementation without having been RDRAND-enabled. >
That is also a good idea for emulation, and especially to provide non-x86 guests with entropy. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
