From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZ7Tp-0007Ex-A5 for qemu-devel@nongnu.org; Mon, 07 Sep 2015 21:13:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZ7To-0006UG-29 for qemu-devel@nongnu.org; Mon, 07 Sep 2015 21:13:49 -0400 Date: Tue, 8 Sep 2015 11:14:01 +1000 From: David Gibson Message-ID: <20150908011401.GF6537@voom.redhat.com> References: <1441046762-5788-1-git-send-email-thuth@redhat.com> <1441046762-5788-3-git-send-email-thuth@redhat.com> <20150901004753.GJ11475@voom.redhat.com> <55EDA7CC.4000905@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0rEjiS+nMGFQ7Kkj" Content-Disposition: inline In-Reply-To: <55EDA7CC.4000905@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 2/2] ppc/spapr_hcall: Implement H_RANDOM hypercall in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: qemu-devel@nongnu.org, agraf@suse.de, armbru@redhat.com, michael@ellerman.id.au, qemu-ppc@nongnu.org, amit.shah@redhat.com --0rEjiS+nMGFQ7Kkj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 07, 2015 at 05:05:48PM +0200, Thomas Huth wrote: > On 01/09/15 02:47, David Gibson wrote: > > On Mon, Aug 31, 2015 at 08:46:02PM +0200, Thomas Huth wrote: > >> The PAPR interface provides a hypercall to pass high-quality > >> hardware generated random numbers to guests. So let's provide > >> this call in QEMU, too, so that guests that do not support > >> virtio-rnd yet can get good random numbers, too. > >> Please note that this hypercall should provide "good" random data > >> instead of pseudo-random, so the function uses the RngBackend to > >> retrieve the values instead of using a "simple" library function > >> like rand() or g_random_int(). Since there are multiple RngBackends > >> available, the user must select an appropriate backend via the > >> "h-random" property of the the machine state to enable it, e.g. > >> > >> qemu-system-ppc64 -M pseries,h-random=3Drng-random ... > ... > >> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c > >> index 652ddf6..ff9d4fd 100644 > >> --- a/hw/ppc/spapr_hcall.c > >> +++ b/hw/ppc/spapr_hcall.c > >> @@ -1,4 +1,8 @@ > >> #include "sysemu/sysemu.h" > >> +#include "sysemu/rng.h" > >> +#include "sysemu/rng-random.h" > >> +#include "qom/object_interfaces.h" > >> +#include "qemu/error-report.h" > >> #include "cpu.h" > >> #include "helper_regs.h" > >> #include "hw/ppc/spapr.h" > >> @@ -929,6 +933,77 @@ static target_ulong h_client_architecture_support= (PowerPCCPU *cpu_, > >> return H_SUCCESS; > >> } > >> =20 > >> +typedef struct HRandomData { > >> + QemuSemaphore sem; > >> + union { > >> + uint64_t v64; > >> + uint8_t v8[8]; > >> + } val; > >> + int received; > >> +} HRandomData; > >> + > >> +static RndRandom *hrandom_rng; > >=20 > > Couldn't you avoid the new global by looking this up through the > > sPAPRMachineState? > >=20 > >> + > >> +static void random_recv(void *dest, const void *src, size_t size) > >> +{ > >> + HRandomData *hrcrdp =3D dest; > >> + > >> + if (src && size > 0) { > >> + memcpy(&hrcrdp->val.v8[hrcrdp->received], src, size); > >=20 > > I'd be happier with an assert() ensuring that size doesn't exceed the > > buffer space we have left. > >=20 > >> + hrcrdp->received +=3D size; > >> + } > >> + qemu_sem_post(&hrcrdp->sem); > >=20 > > Could you avoid a few wakeups by only posting the semaphore once the > > buffer is filled? >=20 > I tried that now, but calling rng_backend_request_entropy() from within > the callback function does not work (since entropy_available() in > rng-random.c clears the callback function variable after having called > the callback). Ah, ok. I'd missed the fact that rng_backend_request_entropy() was being called again - I'd assumed that after the first call the backend would just keep notifying until you had as much data as requested. > And since you normally seem get 8 bytes in the first shot already anyway > when using a good random number generator source, I think it's best to > simply keep the logic as I've currently got it - at least that's easiest > to understand when reading the source code. Yes, I concur. >=20 > >> +} > >> + > >> +static target_ulong h_random(PowerPCCPU *cpu, sPAPRMachineState *spap= r, > >> + target_ulong opcode, target_ulong *args) > >> +{ > >> + HRandomData hrcrd; > >> + > >> + if (!hrandom_rng) { > >> + return H_HARDWARE; > >> + } > >> + > >> + qemu_sem_init(&hrcrd.sem, 0); > >> + hrcrd.val.v64 =3D 0; > >> + hrcrd.received =3D 0; > >> + > >> + qemu_mutex_unlock_iothread(); > >> + while (hrcrd.received < 8) { > >> + rng_backend_request_entropy((RngBackend *)hrandom_rng, > >> + 8 - hrcrd.received, random_recv, = &hrcrd); > >> + qemu_sem_wait(&hrcrd.sem); > >> + } > >> + qemu_mutex_lock_iothread(); > >> + > >> + qemu_sem_destroy(&hrcrd.sem); > >> + args[0] =3D hrcrd.val.v64; > >> + > >> + return H_SUCCESS; > >> +} >=20 > I'll post a new version with the other changes soon. >=20 > Thomas >=20 >=20 --=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 --0rEjiS+nMGFQ7Kkj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV7jZZAAoJEGw4ysog2bOSfH4QAODFrEAy7TuCem1GjrKnDKgJ 9oC1oeWTeVgwYeZeo97N//YJpGxe4NWQJpL1LTGEoecmoz/Hg3Q+3bfDZ+HKIJao LEx6XXiNdrYR1jU/PqPJKMv5l7N2bntwDQnOLk/GvGfVnvZM2NmuZFDtrEBhoBZj mNufoEz12lLwyy9fbHuwTlSuGq2+ahiqkY7CiEj9P7RI7zWVJJgv+jlIqPxGszQ1 SPXJtm/35fOBstVEC7dGMuiVozREv+0IvWp3vAtC2XbGfIcZZt7qrelquvqUBZ0Z zyCL58QqpkPXtwHOMkNri+zP//saQrH9aex//WM95WwRH15E7PZQCOfPPNgPAWVO WEylNuun9ZB/cz94kl28yzQN7Ok/mHqt7yLdfsxqSFhLYQl8/ii/P014eiyFwtO9 j2kwHXY4NZwYMiA21gpZnQKqr6yrMeeCwFdp3jC21eHlTpQk+WnR0V0tWgKwTAtG NIx2oaeU+RZHAJsNoN85Xse8pJmY7I/p/9VaaVsgbioo+a2AwtvGKE+QrMekQnrj 1cWEp+09aZPwZ+V3bVZAdU6cEjvaotDC3zCdIwfiw5NyT6kJMj3x54Rb+n18y/ce oG8nryPaPj3q8gZDOkg4RTAY2TWQooe0t3xvBYUN8i1qRR1ls0eQgqFui/XyqM+q fqMLJC75v0ONmkJLQlPY =3nX1 -----END PGP SIGNATURE----- --0rEjiS+nMGFQ7Kkj--