On Mon, 21 Sep 2015 12:10:00 +1000 David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Sep 18, 2015 at 11:05:52AM +0200, Greg Kurz wrote: > > On Thu, 17 Sep 2015 10:49:41 +0200 > > Thomas Huth <thuth@xxxxxxxxxx> wrote: > > > > > The PAPR interface defines a hypercall to pass high-quality > > > hardware generated random numbers to guests. Recent kernels can > > > already provide this hypercall to the guest if the right hardware > > > random number generator is available. But in case the user wants > > > to use another source like EGD, or QEMU is running with an older > > > kernel, we should also have this call in QEMU, so that guests that > > > do not support virtio-rng yet can get good random numbers, too. > > > > > > This patch now adds a new pseudo-device to QEMU that either > > > directly provides this hypercall to the guest or is able to > > > enable the in-kernel hypercall if available. The in-kernel > > > hypercall can be enabled with the use-kvm property, e.g.: > > > > > > qemu-system-ppc64 -device spapr-rng,use-kvm=true > > > > > > For handling the hypercall in QEMU instead, a "RngBackend" is > > > required since the hypercall should provide "good" random data > > > instead of pseudo-random (like from a "simple" library function > > > like rand() or g_random_int()). Since there are multiple RngBackends > > > available, the user must select an appropriate back-end via the > > > "rng" property of the device, e.g.: > > > > > > qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \ > > > -device spapr-rng,rng=gid0 ... > > > > > > See http://wiki.qemu-project.org/Features-Done/VirtIORNG for > > > other example of specifying RngBackends. > > > > > > Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx> > > > --- > > > > It is a good thing that the user can choose between in-kernel and backend, > > and this patch does the work. > > > > This being said, I am not sure about the use case where a user has a hwrng > > capable platform and wants to run guests without any hwrng support at all is > > an appropriate default behavior... I guess we will find more users that want > > in-kernel being the default if it is available. > > > > The patch below modifies yours to do just this: the pseudo-device is only > > created if hwrng is present and not already created. > > I have mixed feelings about this. On the one hand, I agree that it > would be nice to allow H_RANDOM support by default. On the other hand > the patch below leaves no way to turn it off for testing purposes. It This could be handled with a new spapr property, say 'use-hwrng', defaulting to true. > also adds another place where the guest hardware depends on the host > configuration, which adds to the already substantial mess of ensuring > that source and destination hardware configuration matches for > migration. > Yeah, describing the guest hw is really essential for migration... this is best addressed at the libvirt level with a full XML description of the machine... but FWIW if we are talking about running pseries on a POWER8 or newer host, I am not aware about "hwrng-less" boards... but I am probably missing something :) Back to Thomas' patch, it does the job and brings H_RANDOM, which is currently missing. Acked-by: Greg Kurz <gkurz@xxxxxxxxxxxxxxxxxx> I could test both use-kvm and backend flavors (including migration). Tested-by: Greg Kurz <gkurz@xxxxxxxxxxxxxxxxxx> Thanks. -- Greg
Attachment:
pgp6xfAcwtZrK.pgp
Description: OpenPGP digital signature
