Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/2] spapr: Add support for hwrng when available

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]

On Tue, Sep 08, 2015 at 03:03:16PM +1000, Sam Bobroff wrote:
> On Tue, Sep 01, 2015 at 12:53:26PM +0200, Thomas Huth wrote:
> > On 01/09/15 02:38, David Gibson wrote:
> > > On Mon, Aug 31, 2015 at 08:46:01PM +0200, Thomas Huth wrote:
> > >> From: Michael Ellerman <michael@ellerman.id.au>
> > >>
> > >> Some powerpc systems have support for a hardware random number generator
> > >> (hwrng). If such a hwrng is present the host kernel can provide access
> > >> to it via the H_RANDOM hcall.
> > >>
> > >> The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG
> > >> capability. If this is detected we add the appropriate device tree bits
> > >> to advertise the presence of the hwrng to the guest kernel.
> > >>
> > >> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > >> [thuth: Refreshed patch so it applies to QEMU master branch]
> > >> Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > 
> > > So, I'm confused by one thing.
> > > 
> > > I thought new kernel handled hcalls were supposed to be disabled by
> > > default, but I don't see any calls to kvmppc_enable_hcall() to turn on
> > > H_RANDOM.
> > 
> > Michael's patch was from 2013, the kvmppc_enable_hcall() stuff seems to
> > be from 2014 ... so the enablement is likely missing in this patch,
> > indeed. I didn't test the in-kernel hypercall yet, just my QEMU
> > implementation so far, that's why I did not notice this yet.
> > 
> > Michael, do you want to rework your patch? Or shall I add an additional
> > enablement patch to my queue?
> 
> If I recall correctly, it's specifically not enabled: there was quite a lot of
> discussion about it when Michael posted the patches and I think the consensus
> was that it should only be enabled by QEMU, and only if the user could decide
> if it was used or not.
> 
> What if we set up another backend that just enables the hcall in KVM?

I think that's basically the right approach.

It can't quite be a "backend" as such, since the in-kernel hcall can
only supply H_RANDOM; it can't supply random for other purposes like
virtio-rng, which the general qemu rng backends can.

So I'd suggest two options controlling H_RANDOM:
	usekvm : boolean  [default true]
		Whether to enable the in-kernel implementation if
		available
	backend : ref to rng backend object [no default]
		Backend to use if in-kernel implementation is
		unavailable or disabled.

At this point rather than just implementing them as discrete machine
options, I suspect it will be more maintainable to split out the
h-random implementation as a pseudo-device with its own qdev and so
forth.  We already do similarly for the RTAS time of day functions
(spapr-rtc).

-- 
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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]