From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za0fW-0003sM-Ce for qemu-devel@nongnu.org; Thu, 10 Sep 2015 08:09:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za0fT-0004JF-3l for qemu-devel@nongnu.org; Thu, 10 Sep 2015 08:09:34 -0400 Received: from e06smtp15.uk.ibm.com ([195.75.94.111]:35707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za0fS-0004IY-QR for qemu-devel@nongnu.org; Thu, 10 Sep 2015 08:09:31 -0400 Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 10 Sep 2015 13:09:27 +0100 Date: Thu, 10 Sep 2015 14:06:31 +0200 From: Greg Kurz Message-ID: <20150910140631.421bfb61@bahia.local> In-Reply-To: <20150909005420.GA4324@tungsten.ozlabs.ibm.com> References: <1441046762-5788-1-git-send-email-thuth@redhat.com> <1441046762-5788-2-git-send-email-thuth@redhat.com> <20150901003808.GI11475@voom.redhat.com> <55E583A6.4000600@redhat.com> <20150908050316.GA372@tungsten.ozlabs.ibm.com> <55EE7444.6060707@redhat.com> <20150909005420.GA4324@tungsten.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/2] spapr: Add support for hwrng when available List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sam Bobroff Cc: Thomas Huth , qemu-devel@nongnu.org, armbru@redhat.com, michael@ellerman.id.au, qemu-ppc@nongnu.org, amit.shah@redhat.com, David Gibson On Wed, 9 Sep 2015 10:54:20 +1000 Sam Bobroff 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 > > >>>> > > >>>> 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 > > >>>> [thuth: Refreshed patch so it applies to QEMU master branch] > > >>>> Signed-off-by: Thomas Huth > > >>> > > >>> 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