From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZmdL-0006bS-5L for qemu-devel@nongnu.org; Wed, 09 Sep 2015 17:10:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZmdI-0006WN-Fj for qemu-devel@nongnu.org; Wed, 09 Sep 2015 17:10:23 -0400 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> <20150908051528.GD24774@voom.redhat.com> From: Thomas Huth Message-ID: <55F0A036.2090508@redhat.com> Date: Wed, 9 Sep 2015 23:10:14 +0200 MIME-Version: 1.0 In-Reply-To: <20150908051528.GD24774@voom.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AkEjgiBuOSXvmWLlsHARvQEC0QlFad2x4" 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: David Gibson , Sam Bobroff Cc: michael@ellerman.id.au, amit.shah@redhat.com, qemu-ppc@nongnu.org, armbru@redhat.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AkEjgiBuOSXvmWLlsHARvQEC0QlFad2x4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/09/15 07:15, David Gibson wrote: > 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 >>>>> >>>>> Some powerpc systems have support for a hardware random number gene= rator >>>>> (hwrng). If such a hwrng is present the host kernel can provide acc= ess >>>>> to it via the H_RANDOM hcall. =2E.. >> What if we set up another backend that just enables the hcall in KVM? >=20 > I think that's basically the right approach. >=20 > 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. >=20 > 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. >=20 > 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). I gave that I try, but it does not work as expected. To be able to specify the options, I'd need to instantiate this device with the "-device" option, right? Something like: -device spapr-rng,backend=3Drng0,usekvm=3D0 Now this does not work when I use TYPE_SYS_BUS_DEVICE as parent class like it is done for spapr-rtc, since the user apparently can not plug device to this bus on machine spapr (you can also not plug an spapr-rtc device this way!). The spapr-vlan, spapr-vty, etc. devices are TYPE_VIO_SPAPR_DEVICE, so I also tried that instead, but then the rng device suddenly shows up under /vdevice in the device tree - that's also not what we want, I guess. So I am currently not sure whether this is the right approach. Any recommendations? Or shall I stick with the machine option? Thomas --AkEjgiBuOSXvmWLlsHARvQEC0QlFad2x4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV8KA2AAoJEC7Z13T+cC21cLwQALMAa2WiXdK1KffW8vbzAYMp wokowyuCfwx8zP6YdC8fanlaq5PEJf0Mej16L2uIlQlneNESuQkbud69FQVBWNx/ pd319mk0Pf6NJhbioUvZ8HLZia74PtB0LKNC33PzzyycNHR4if+aURGCCyjTzxrc YY3gIAqttiz7R7pmIHiObEe5IX4PIMucEpX1Rv9CK1I5qEXhCeFCHXdL/63ye3Hx vg4FaYBwWxYYWhgda2t4tY9Hnj3JBY1Cxu75BqqHT6MLjHhZZXtVYbPyGvq8cP9D eCD2IhIYBvCcYAna3LW7PL7o+S7Uo3n8MozNotspgtpyPW2/H1nXf6N2tqA5luTu wy9Nc8OqPwk9mRRi1JXUvdzzEm9WIBd8fJmt4scui2CfPyX3t8lUowp9DAZ7SYbU ibAmRvRDpmhazizbO2C2ArGKnofuesSO/kG2Gyv+pCP6RVtXP7iOM5Qo0KcAvuIv nWo8MMf7Sb3JpD99AfMI39Zyee82hQTU9mH11yAvTXEAtstaSYg2xwyMldBUp1Y6 ogFyw+qiO/zAz5944iIItHYpJxrxD5GXZUoahpCGWTphq7i1N0b0aHnHNHDN1Mg/ ZGSPkSWHtFPaaN+JOSd+JTgD2oMoFy6Ytfc+CkMVf8bVeYI9Bj9otmrKN5M5Nstf xlIBiwPu3jujMAtoL/10 =tJIK -----END PGP SIGNATURE----- --AkEjgiBuOSXvmWLlsHARvQEC0QlFad2x4--