From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zdu9s-0007Z2-D8 for qemu-devel@nongnu.org; Mon, 21 Sep 2015 02:01:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zdu9o-00027B-CW for qemu-devel@nongnu.org; Mon, 21 Sep 2015 02:01:00 -0400 References: <1442479781-20164-1-git-send-email-thuth@redhat.com> <20150918110552.6487a506@bahia.local> <20150921021000.GI20331@voom.fritz.box> From: Thomas Huth Message-ID: <55FF9CE2.7060403@redhat.com> Date: Mon, 21 Sep 2015 08:00:02 +0200 MIME-Version: 1.0 In-Reply-To: <20150921021000.GI20331@voom.fritz.box> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kMfeStkW4lLmlsWLcLDhABph0j8WsTqqr" 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: David Gibson , Greg Kurz Cc: 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 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kMfeStkW4lLmlsWLcLDhABph0j8WsTqqr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 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=3Dtrue >>> >>> 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=3D/dev/hwrng,id=3Dgid0= \ >>> -device spapr-rng,rng=3Dgid0 ... >>> >>> See http://wiki.qemu-project.org/Features-Done/VirtIORNG for >>> other example of specifying RngBackends. >>> >>> Signed-off-by: Thomas Huth >>> --- >> >> It is a good thing that the user can choose between in-kernel and back= end, >> and this patch does the work. >> >> This being said, I am not sure about the use case where a user has a h= wrng >> 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 tha= t want >> in-kernel being the default if it is available. >> >> The patch below modifies yours to do just this: the pseudo-device is o= nly >> created if hwrng is present and not already created. >=20 > 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 --kMfeStkW4lLmlsWLcLDhABph0j8WsTqqr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV/5znAAoJEC7Z13T+cC21rQkP+wQ1YJozdtLUTw9FhYiwEwBW /g4r7vZhzT4ss6KE8bPNuzYHQviG9jYfWsx+e2OdNIpbfPzA3gij/6L8wqpB6RTt 8Y9iQNiYfqxPo0BZ8KDGE6/TTQISCGs4Beuf5F4BriSIJUOnAID8E0FiPkJfXd3T U6OqplGGQ2Y6fyIt+/OPRxl88l22hmscyW7n1HSYQY2X2qFi9sjmHdyq02i0PKLx Vx+ikuluOi2fpfHif4xpLfiOn1yz5HtzeZD29NgMH5bYv2rSj8N4zbvM6CLWmxi5 sQ7jeoOblBvnimCbxPjBWXsn9WU6j4jeY/RbFs/KT6UWO2aBo2X/5K2KFK8WGKPO 7M6WqOibGG8ypV+Fl0jSLQ/cinYnA6OMXtv1YuYujp8jpaNEROQqR4b13DacNzTM HM+uaOy6GUPQB5GyuPBummpYzc2yrTClzR5jiuctNYCzn+nBGoe+Gr94BL4aeO0V GabEul3XzB7whKUsDC/wlfCRjhH6hn0wgTkWWaS/BvkSzo6Z2wGZlP/Q1Xi9+QkA vswe063I4qQejpIiL7X17XFL4Pl19IRAtgV4SaiT6feEHJrHkTuEsTP8B7kPjkIK m7AlADIa34QHeObPqhVHGk9yDwptUeD0BtgrHVv3Ql21cpBcwFinaDOXLnjzR4Mu nREXARudJVynSrssLO00 =PCz8 -----END PGP SIGNATURE----- --kMfeStkW4lLmlsWLcLDhABph0j8WsTqqr--