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

[Greg Kurz]

On Wed, 9 Sep 2015 10:54:20 +1000
Sam Bobroff <address@hidden> wrote:

> On Tue, Sep 08, 2015 at 07:38:12AM +0200, Thomas Huth wrote:
> > On 08/09/15 07:03, 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 <address@hidden>
> > >>>>
> > >>>> 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 <address@hidden>
> > >>>> [thuth: Refreshed patch so it applies to QEMU master branch]
> > >>>> Signed-off-by: Thomas Huth <address@hidden>
> > >>>
> > >>> 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.
> > 
> > Can you find this discussion in a mailing list archive somewhere? The
> > only discussions I've found are basically these:
> > 
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-09/msg04233.html
> > https://lkml.org/lkml/fancy/2013/10/1/49
> > 
> > ... and there it was only discussed that the call should be implemented
> > in QEMU, too. I did not spot any discussion about making it switchable
> > for the user?
> 
> Sorry that part wasn't very well worded: I was trying to say that QEMU's
> configuration should be able to choose how H_RANDOM handled, rather than 
> having
> it automatically choose based on what was available in KVM and that's what
> we're considering now anyway. (See David's comment elsewhere in this thread.)
> 
> Sam.
> 
> 

In this case, this patch isn't appropriate anymore: QEMU would advertise support
for "ibm,random-v1" but guests would be returned H_FUNCTION. The DT bits should
be in a later patch, after H_RANDOM is plugged in (either KVM or QEMU).

Cheers.

--
Greg