On Mon, Sep 21, 2015 at 10:37:28AM +0200, Greg Kurz wrote: > On Mon, 21 Sep 2015 10:26:52 +0200 > Thomas Huth <thuth@xxxxxxxxxx> wrote: > > > On 21/09/15 10:01, Greg Kurz wrote: > > > 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. > > ... > > >>> 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. > > > > > > 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 :) > > > > Maybe it would be at least ok to enable it by default as long as > > "-nodefaults" has not been specified as command line option? I like that in principle, but the -nodefaults option isn't exposed outside vl.c > It makes a lot of sense indeed. I guess David should take your patch > as it is now and the default behavior could be a follow up. That's the plan. I've already taken the base patch. -- 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:
pgpnS7zQ3EoAg.pgp
Description: PGP signature
