From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeD9Z-0000Dv-2P for qemu-devel@nongnu.org; Mon, 21 Sep 2015 22:17:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeD9V-0005bJ-2W for qemu-devel@nongnu.org; Mon, 21 Sep 2015 22:17:57 -0400 Date: Tue, 22 Sep 2015 11:38:20 +1000 From: David Gibson Message-ID: <20150922013820.GN20331@voom.fritz.box> References: <1442479781-20164-1-git-send-email-thuth@redhat.com> <20150918110552.6487a506@bahia.local> <20150921021000.GI20331@voom.fritz.box> <20150921100157.3d6561aa@bahia.local> <55FFBF4C.9030908@redhat.com> <20150921103728.5524d0ce@bahia.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DH4/xewco2zMcht6" Content-Disposition: inline In-Reply-To: <20150921103728.5524d0ce@bahia.local> Subject: Re: [Qemu-devel] [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: Thomas Huth , agraf@suse.de, kvm-ppc@vger.kernel.org, qemu-devel@nongnu.org, michael@ellerman.id.au, qemu-ppc@nongnu.org, amit.shah@redhat.com, sam.bobroff@au1.ibm.com --DH4/xewco2zMcht6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2015 at 10:37:28AM +0200, Greg Kurz wrote: > On Mon, 21 Sep 2015 10:26:52 +0200 > Thomas Huth wrote: >=20 > > On 21/09/15 10:01, Greg Kurz wrote: > > > On Mon, 21 Sep 2015 12:10:00 +1000 > > > David Gibson wrote: > > >=20 > > >> On Fri, Sep 18, 2015 at 11:05:52AM +0200, Greg Kurz wrote: > > >>> On Thu, 17 Sep 2015 10:49:41 +0200 > > >>> Thomas Huth 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 b= ackend, > > >>> 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 i= s 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 ha= nd > > >> 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. > > >=20 > > > Yeah, describing the guest hw is really essential for migration... th= is > > > 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 :) > >=20 > > 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. --=20 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 --DH4/xewco2zMcht6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWALEMAAoJEGw4ysog2bOSyZsP/RSWt2XU/CwrW3u53NSdj8Nx Tl32Si0vLXTLoHN2wh5Grl1tIGFgy14OrxeHaGMNGp1GnLh28XCJsLBgA1USMffD BLyA8jAWBlv23j8ATNXqdbzh6AOTJIIua5iKrahvYMFHvT70pUvtaFrsCYZrVbOx Xn/F2YDM78BH5o8DEoDF2uhNN0lYrFxkVX+SWHkgikLbyy8XLpzvXELvAthB4Hsr 3UglrS2iWh/tVkA1fzG3WqsdZzY3w7sgBJT3yOZklhGcxZXDvdsqutus3FDMNBn7 yAxoYdbqA9rKiTmE/xn3d8+YfRNDBX5hLCwNTtkT5eLw2XuclRFCnEx+tnwH78uz RUbAb5qfv2URY2A5jx0Vgqvs/Qa0p+R1I8SIv5PVU1RnvEdHA6LEpvJ+KY+7FpBR Z6++sJupErA1/I0TajcyCd92RiRmnEnfU2VTmvVHTwpbxQ9rPoTzfnUcmOYJ+MQJ QvN/yQhTyZWQM9VO1fZ4rmIM8Y4y4fYNMXkPfzBa6wshAH1KFTkonJtlrOrxywf6 wSqpOB2tUkiYTCoNiYFJqov4QmHDWLEQb8o+mYaniRs/5b3fiRAtGeOcYLNIBtaX aqYKgVLRSM5CzEuVEE5EtenwuJsZTWG8CPCR7ITCiQvWe4j21GDQTWP9OmWd0LDT fYWwJgwtoZv7+Z8+DfaQ =97D2 -----END PGP SIGNATURE----- --DH4/xewco2zMcht6--