Re: [Qemu-devel] [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2838 bytes --]

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@redhat.com> 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@redhat.com>
> > ---
> 
> 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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]