From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZX0gj-0005wI-Fj for qemu-devel@nongnu.org; Wed, 02 Sep 2015 01:34:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZX0ge-0005MO-FS for qemu-devel@nongnu.org; Wed, 02 Sep 2015 01:34:25 -0400 Date: Wed, 2 Sep 2015 11:04:12 +0530 From: Amit Shah Message-ID: <20150902053412.GE13778@grmbl.mre> References: <1441046762-5788-1-git-send-email-thuth@redhat.com> <1441046762-5788-3-git-send-email-thuth@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441046762-5788-3-git-send-email-thuth@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: armbru@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, michael@ellerman.id.au, qemu-ppc@nongnu.org, david@gibson.dropbear.id.au 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. 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. > 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=rng-random ... > > to use the /dev/random backend, or "h-random=rng-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? > +static void random_recv(void *dest, const void *src, size_t size) > +{ > + HRandomData *hrcrdp = dest; > + > + if (src && size > 0) { > + memcpy(&hrcrdp->val.v8[hrcrdp->received], src, size); > + hrcrdp->received += size; > + } > + qemu_sem_post(&hrcrdp->sem); > +} > + > +static target_ulong h_random(PowerPCCPU *cpu, sPAPRMachineState *spapr, > + target_ulong opcode, target_ulong *args) > +{ > + HRandomData hrcrd; > + > + if (!hrandom_rng) { > + return H_HARDWARE; > + } > + > + qemu_sem_init(&hrcrd.sem, 0); > + hrcrd.val.v64 = 0; > + hrcrd.received = 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? > + qemu_mutex_lock_iothread(); > + > + qemu_sem_destroy(&hrcrd.sem); > + args[0] = hrcrd.val.v64; > + > + return H_SUCCESS; > +} Amit