From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zdw3V-0001Sz-D0 for qemu-devel@nongnu.org; Mon, 21 Sep 2015 04:02:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zdw3S-0004OP-6O for qemu-devel@nongnu.org; Mon, 21 Sep 2015 04:02:33 -0400 Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:33129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zdw3R-0004O7-UE for qemu-devel@nongnu.org; Mon, 21 Sep 2015 04:02:30 -0400 Received: from /spool/local by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 21 Sep 2015 09:02:27 +0100 Date: Mon, 21 Sep 2015 10:01:57 +0200 From: Greg Kurz Message-ID: <20150921100157.3d6561aa@bahia.local> In-Reply-To: <20150921021000.GI20331@voom.fritz.box> References: <1442479781-20164-1-git-send-email-thuth@redhat.com> <20150918110552.6487a506@bahia.local> <20150921021000.GI20331@voom.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/K1JKiF0dirxtryGh3jDDcdy"; protocol="application/pgp-signature" 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 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 --Sig_/K1JKiF0dirxtryGh3jDDcdy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 21 Sep 2015 12:10:00 +1000 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: > >=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 backe= nd, > > and this patch does the work. > >=20 > > This being said, I am not sure about the use case where a user has a hw= rng > > capable platform and wants to run guests without any hwrng support at a= ll is > > an appropriate default behavior... I guess we will find more users that= want > > in-kernel being the default if it is available. > >=20 > > The patch below modifies yours to do just this: the pseudo-device is on= ly > > 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 This could be handled with a new spapr property, say 'use-hwrng', defaulting to true. > 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... 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 :) Back to Thomas' patch, it does the job and brings H_RANDOM, which is currently missing. Acked-by: Greg Kurz I could test both use-kvm and backend flavors (including migration). Tested-by: Greg Kurz Thanks. -- Greg --Sig_/K1JKiF0dirxtryGh3jDDcdy Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlX/uXYACgkQAvw66wEB28LNdgCfdIEZi/TablcEUNDaedtSnFEX bg4An2LJnFI96EKs9OyA5x+sQIjRdOnM =y8Cw -----END PGP SIGNATURE----- --Sig_/K1JKiF0dirxtryGh3jDDcdy--