From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zdqef-00018p-GH for qemu-devel@nongnu.org; Sun, 20 Sep 2015 22:16:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zdqec-0007Pk-AC for qemu-devel@nongnu.org; Sun, 20 Sep 2015 22:16:33 -0400 Date: Mon, 21 Sep 2015 12:10:00 +1000 From: David Gibson Message-ID: <20150921021000.GI20331@voom.fritz.box> References: <1442479781-20164-1-git-send-email-thuth@redhat.com> <20150918110552.6487a506@bahia.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lqaZmxkhekPBfBzr" Content-Disposition: inline In-Reply-To: <20150918110552.6487a506@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 --lqaZmxkhekPBfBzr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > > 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. > >=20 > > 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.: > >=20 > > qemu-system-ppc64 -device spapr-rng,use-kvm=3Dtrue > >=20 > > 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.: > >=20 > > qemu-system-ppc64 -object rng-random,filename=3D/dev/hwrng,id=3Dgid0 \ > > -device spapr-rng,rng=3Dgid0 ... > >=20 > > See http://wiki.qemu-project.org/Features-Done/VirtIORNG for > > other example of specifying RngBackends. > >=20 > > Signed-off-by: Thomas Huth > > --- >=20 > It is a good thing that the user can choose between in-kernel and backend, > and this patch does the work. >=20 > 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 w= ant > in-kernel being the default if it is available. >=20 > 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. --=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 --lqaZmxkhekPBfBzr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV/2b4AAoJEGw4ysog2bOSM/oP/RoWJUQSwTT40YM0pKPgQXQh X2tpZiUxrCLkBbkXfSrKxpCcVYqz0JTin9ajTMIEAzRYdKOzc6OZyftKkRTVPmKA WSDHAMnaKupzkXPH8gHNYGUj6DC4vGdDBgo9i+h0OW1/DZqc5TE7TcEbAGu92UJ3 LQ5o4CsxmJEGYWor1lahAygWwxOS86kbVpy0m3KW8oRGchbWeu+yDVbOhxzoDN9m I/9RkFKqjxG5IfuKBo/LQMuVXHQ1omOMYcpXssgimGdDq6dkPnb7Qjk6xI4Zv+bD 0I2t6iyW+yWgu5PGfbrgEa+7fTL7hz212YEPm0H11+FW8/Pk9sJyK8EnwECkN9wL rKX9wzgvxPB17kOkW84P7tv5E0Qx8rpX7jffexEYVKaOENcF1NvpIts8i43HsWoP 8eSKwB7gcwuyMA/c3Zdyo3OAT1OECqu6B9ERqKolhWOM7pYfgBOOWB0sHXoE4QjK SWaonkfIOpoZkvDvXOH7aiSqhrgUTxU/K3etHc/k4ei2T0X96gK8TIZL6M4Mazj+ PawU0UeUQJvTJPbuV5N4h5ONT2ZddfRdsCPTJGFgs/SoZPEMv9EWXBdyW7Gnrqsz N/SnR+CvSmbRwRl8kJz9zmyIHjmDAMXyF3p5rf4BgbJkk3vDWk32ZjPM1wrwEvp1 pT32ckrkpGa105EPD/LR =9KRk -----END PGP SIGNATURE----- --lqaZmxkhekPBfBzr--