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 1ZX3sq-0002R0-UE for qemu-devel@nongnu.org; Wed, 02 Sep 2015 04:59:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZX3sl-0007YW-T6 for qemu-devel@nongnu.org; Wed, 02 Sep 2015 04:59:08 -0400 References: <1441046762-5788-1-git-send-email-thuth@redhat.com> <1441046762-5788-3-git-send-email-thuth@redhat.com> <20150902053412.GE13778@grmbl.mre> <20150902074801.GA6537@voom.redhat.com> From: Thomas Huth Message-ID: <55E6BA51.60605@redhat.com> Date: Wed, 2 Sep 2015 10:58:57 +0200 MIME-Version: 1.0 In-Reply-To: <20150902074801.GA6537@voom.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9p4grwoHmb07Mm2SGjfoINSG1NxcLv0qG" 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: David Gibson , Amit Shah Cc: michael@ellerman.id.au, armbru@redhat.com, qemu-ppc@nongnu.org, agraf@suse.de, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9p4grwoHmb07Mm2SGjfoINSG1NxcLv0qG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/09/15 09:48, David Gibson wrote: > On Wed, Sep 02, 2015 at 11:04:12AM +0530, Amit Shah wrote: >> On (Mon) 31 Aug 2015 [20:46:02], 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. >> >> virtio-rng, not rnd. Oh, sorry, I'll fix the description. >> Can you elaborate what you mean by 'guests that do not support >> virtio-rng yet'? The Linux kernel has had the virtio-rng driver since= >> 2.6.26, so I'm assuming that's not the thing you're alluding to. >> >> Not saying this hypercall isn't a good idea, just asking why. I think= >> there's are valid reasons like the driver fails to load, or the driver= >> is compiled out, or simply is loaded too late in the boot cycle. >=20 > Yeah, I think we'd be talking about guests that just don't have it > configured, although I suppose it's possible someone out there is > using something earlier than 2.6.26 as well. Note that H_RANDOM has > been supported under PowerVM for a long time, and PowerVM doesn't have > any virtio support. So it is plausible that there are guests out > there with with H_RANDOM support but no virtio-rng support, although I > don't know of any examples specifically. RHEL6 had virtio support, > including virtio-rng more or less by accident (since it was only > supported under PowerVM). SLES may not have made the same fortunate > error - I don't have a system handy to check. Right, thanks David, I couldn't have explained it better. >>> 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 ... >>> >>> to use the /dev/random backend, or "h-random=3Drng-egd" to use the >>> Entropy Gathering Daemon instead. >> >> I was going to suggest using -object here, but already I see you and >> David have reached an agreement for that. >> >> Out of curiosity: what does the host kernel use for its source when >> going the hypercall route? >=20 > I believe it draws from the same entropy pool as /dev/random. The H_RANDOM handler in the kernel uses powernv_get_random_real_mode() in arch/powerpc/platforms/powernv/rng.c ... that seems to be a powernv-only pool (but it is also used to feed the normal kernel entropy pool, I think), but I am not an expert here so I might be wrong. >>> +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); >>> + hrcrdp->received +=3D size; >>> + } >>> + qemu_sem_post(&hrcrdp->sem); >>> +} >>> + >>> +static target_ulong h_random(PowerPCCPU *cpu, sPAPRMachineState *spa= pr, >>> + 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); >>> + } >> >> Is it possible for a second hypercall to arrive while the first is >> waiting for the backend to provide data? >=20 > Yes it is. The hypercall itself is synchronous, but you could get > concurrent calls from different guest CPUs. Hence the need for > iothread unlocking. BQL and semaphore handling should be ok, I think, but one remaining question is: Can the RngBackend deal with multiple requests in flight from different vCPUs? Or is it limited to one consumer only? Amit, do you know this? Thomas --9p4grwoHmb07Mm2SGjfoINSG1NxcLv0qG 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) iQIbBAEBAgAGBQJV5rpRAAoJEC7Z13T+cC21gD0P+NN2y21cSqmpWK0GKQs5zdns T+k4tfxuG4nSgekP/1LM7tbM0bhrp/37wIlDjYPprC/sd0MMIT+g04WqwbJZEiCE L5cvzmGoc+NNTpydpQdeii3bXMt3ubClsIfLfD987st+/y0wqPS2bTLxFBB0M3ez b1ScbL3qT2otqRiIrDRD3EVQoosQqvrgYOozVoS9hcdi1g3fWdQeByNlu0S1Kv5w PVuCJrzUbhrRGxxUX66IWxUXnwslMhvgry2RPczpwAP7eFv7RYP4BIjqvclS9vXY Iprp8WYjRv7lCzgMX5iDGQ8Ll48S8IPcwTPp1c7d0eoIGE970Ib4kZGX2s38qQVs 8teGXtEoJVVekfeSXOgcK9cCiwaQ3FO72JTOsSmOT1AbGTtorGqvWQsV84ZOY70X hs7KuUFjRE6SoqN3WyWIG1YvDaud0VSmvoA5zmKDdIG5h3qv8ZSL96sZ/xNkuhCp mrKpdkVs0OZMB3Vd8PBAqATz5YaNpqu7lpuNt2klf3toUfFXs5d25wZp5SH5xQUI aaka3Vc+Qbvr1O8GjS5FBMNizgOx3D1tJ9oLuiVPgZJRphjdKVtVrS0mZL3WTTAu aSKKmAzTo1OmWYaOv5LJgOLIFQNQ4N8CecCaFTBzsCIQJYTDeVEW++KWzwfsabYx XELFdYZU1eaHhOGUjlo= =adJU -----END PGP SIGNATURE----- --9p4grwoHmb07Mm2SGjfoINSG1NxcLv0qG--