On 21/09/15 04:10, David Gibson 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 > 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. I thought about this question on the weekend and came to the same conclusion. I think if we want to enable this by default, it likely should rather be done at the libvirt level instead? Thomas
Attachment:
signature.asc
Description: OpenPGP digital signature
