From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYDxf-0004sz-54 for qemu-devel@nongnu.org; Fri, 12 Aug 2016 11:01:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYDxc-0001Kj-Sc for qemu-devel@nongnu.org; Fri, 12 Aug 2016 11:01:26 -0400 References: <1470591415-3268-1-git-send-email-nikunj@linux.vnet.ibm.com> <1470591415-3268-3-git-send-email-nikunj@linux.vnet.ibm.com> <1470605617.12584.182.camel@kernel.crashing.org> <20160809032817.GG9057@voom.fritz.box> <87invaa6fg.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> <87d1li9u85.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> <20160812062917.GT16493@voom.fritz.box> <87fuqa8p22.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> <3c439ecd-57dc-eabe-fc68-d8c7cdce9e44@redhat.com> <87a8gi8mh6.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> From: Thomas Huth Message-ID: Date: Fri, 12 Aug 2016 09:55:18 +0200 MIME-Version: 1.0 In-Reply-To: <87a8gi8mh6.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/6] target-ppc: Implement darn instruction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikunj A Dadhania , David Gibson Cc: Ravi Bangoria , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, rth@twiddle.net On 12.08.2016 09:39, Nikunj A Dadhania wrote: > Thomas Huth writes: >=20 >> On 12.08.2016 08:43, Nikunj A Dadhania wrote: >>> David Gibson writes: >>> >>>> [ Unknown signature status ] >>>> On Tue, Aug 09, 2016 at 02:47:46PM +0530, Nikunj A Dadhania wrote: >>>>> Nikunj A Dadhania writes: >>>>> >>>>>> David Gibson writes: >>>>>> >>>>>>> [ Unknown signature status ] >>>>>>> On Mon, Aug 08, 2016 at 07:33:37AM +1000, Benjamin Herrenschmidt = wrote: >>>>>>>> On Sun, 2016-08-07 at 23:06 +0530, Nikunj A Dadhania wrote: >>>>>>>>> +target_ulong helper_darn(uint32_t l) >>>>>>>>> +{ >>>>>>>>> + target_ulong r =3D UINT64_MAX; >>>>>>>>> + >>>>>>>>> + if (l <=3D 2) { >>>>>>>>> + do { >>>>>>>>> + r =3D random() * random(); >>>>>>>>> + r &=3D l ? UINT64_MAX : UINT32_MAX; >>>>>>>>> + } while (r =3D=3D UINT64_MAX); >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + return r; >>>>>>>>> +} >>>>>>>>> #endif >>>>>>>> >>>>>>>> Isn't this a bit week ? Look at the implementation of H_RANDOM..= . >>>>>>> >>>>>>> Indeed, you should be using the rng backend that H_RANDOM, virtio= -rng >>>>>>> and the Intel random number instruction all use. >>>>> >>>>> Can you point me to the intel instruction, I couldn't get rdrand >>>>> implementation. >>>> >>>> Ah.. turns out no. I'd assumed it was there and used the same backe= nd >>>> as virtio-rng and H_RANDOM, but I hadn't actually looked at the code= , >>>> and now that I'm trying I can't see it either. >>>> >>>>> >>>>>> I was looking at implementing this, AFAIU, I have to get a new RNG >>>>>> object in the initialization routine. We would need an instance of= this >>>>>> per machine. So for pseries I can add in ppc_spapr_init(). I am no= t sure >>>>>> in case of linux-user where should this be initialized. >>>>>> >>>>>> One other place was init_proc_POWER9(), but that will be per cpu a= nd >>>>>> member of CPUPPCState structure. Advantage is it will work for sys= tem >>>>>> emulation and linux-user both and we would not need a lock. >>>>> >>>>> More issues here. Random backend is not compiled for linux-user, ad= ding >>>>> that wasn't difficult, but then rng_backend_request_entropy() uses >>>>> qemu_set_fd_handler() which is a stub for linux-user >>>>> (stubs/set-fd-handler.c)7 >>>> >>>> >>>> Ah.. yeah, not sure how we'll need to handle that. >>> >>> I have sent updated patch, reading from /dev/random. Not sure if that= is >>> allowed in tcg. Works fine though. >> >> You can not rely on /dev/random for this job, since it might block. So >> your guest would stop executing when there is not enough random data >> available in the host, and I think that's quite a bad behavior... >=20 > Hmm.. rng-random does use this, but it might have way to time out proba= bly: >=20 > backends/rng-random.c: s->filename =3D g_strdup("/dev/random"); This is only the default value, which is likely suitable for virtio-rng, but not for something like this instruction (or the H_RANDOM hypercall). You can set the filename property to another file when instantiating it, like: qemu-system-xxx ... -object rng-random,filename=3D/dev/hwrng,id=3Drng0 .= .. That's the whole point these backends - you give the users the possibility to chose the right source of entropy. For example, on the POWER8 machine that I have here, /dev/random blocks after a couple of bytes, you can see that easily by typing something like "hexdump /dev/random". It only delivers more random data when I run "rngd -r /dev/hwrng" in the background. Thomas