From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNJvK-0000Yr-TV for qemu-devel@nongnu.org; Thu, 06 Aug 2015 08:05:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNJvC-0008LF-De for qemu-devel@nongnu.org; Thu, 06 Aug 2015 08:05:26 -0400 Message-ID: <55C34D79.5010802@redhat.com> Date: Thu, 06 Aug 2015 14:05:13 +0200 From: Thomas Huth MIME-Version: 1.0 References: <1438849438-18552-1-git-send-email-thuth@redhat.com> <55C34453.3080104@redhat.com> In-Reply-To: <55C34453.3080104@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH] ppc/spapr_hcall: Implement H_RANDOM hypercall List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier , qemu-ppc@nongnu.org, agraf@suse.de, david@gibson.dropbear.id.au Cc: qemu-devel@nongnu.org On 06/08/15 13:26, Laurent Vivier wrote: > Hi, >=20 > As "/dev/random" can be blocking perhaps it is possible/better to use > the QEMU rng backend instead ? Actually, I tried to use the rng backends first ... but they turned out to be horrible for being used in a synchronous call like I need here: You've got to install a callback function which is called at a "random" point in time when some data becomes available - and it is even called with less bytes than you requested! (i.e. I requested 8 bytes, but the callback got only called with 6 bytes). So to use it, I'd have to introduce a ring buffer or something similar to query enough random data in advance - and when it runs empty, the H_RANDOM hypercall would need to block again anyway. So instead of introducing a hard-to-understand-and-maintain "monster wrapper" around the rng backend functions, I think the short and easy understandable qemu_random() implementation in this patch here is the better choice. And looking at https://patchwork.ozlabs.org/patch/497062/ I think it also should not hurt too much that qemu_random() might be slow here since the real hardware number generator is apparently also not very fast= . Thomas > On 06/08/2015 10:23, Thomas Huth wrote: >> The spapr firmware SLOF likely needs a way to get random numbers >> soon. Instead of re-inventing the wheel there, we could simply >> use the H_RANDOM hypercall to get the random numbers from QEMU. >> For this the H_RANDOM hypercall needs to be implemented first, of >> course. >> So this patch introduces an OS-specifc helper function called >> qemu_random() to get "good" random numbers (from /dev/random on >> POSIX systems and via CryptGenRandom() on Windows), and then uses >> this helper functions to provide random data to the guest via the >> H_RANDOM hypercall. >> >> Signed-off-by: Thomas Huth >> --- >> Note: Since I do not have access to the SPAPR spec, I figured out >> the calling conventions of the hypercall by looking at the way >> the Linux kernel is using this call to retriev random data. So >> there might be some bugs or missing pieces here. >> >> Also note that the Windows version of qemu_random() is >> compile-tested only (with a MinGW cross-compiler), since I do not >> have access to a Windows system right now. >> >> hw/ppc/spapr_hcall.c | 12 ++++++++++++ >> include/hw/ppc/spapr.h | 1 + >> include/qemu/osdep.h | 11 +++++++++++ >> util/oslib-posix.c | 16 ++++++++++++++++ >> util/oslib-win32.c | 17 +++++++++++++++++ >> 5 files changed, 57 insertions(+)