From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZzHT-0000SZ-9z for qemu-devel@nongnu.org; Thu, 10 Sep 2015 06:40:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZzHP-0007vV-U6 for qemu-devel@nongnu.org; Thu, 10 Sep 2015 06:40:39 -0400 Date: Thu, 10 Sep 2015 20:40:51 +1000 From: David Gibson Message-ID: <20150910104051.GC11781@voom> 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> <55F0A036.2090508@redhat.com> <55F13241.8040004@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Uq4LBwYP4y1W6pO" Content-Disposition: inline In-Reply-To: <55F13241.8040004@redhat.com> 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: Thomas Huth Cc: armbru@redhat.com, qemu-devel@nongnu.org, michael@ellerman.id.au, qemu-ppc@nongnu.org, amit.shah@redhat.com, Sam Bobroff --/Uq4LBwYP4y1W6pO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 10, 2015 at 09:33:21AM +0200, Thomas Huth wrote: > On 09/09/15 23:10, Thomas Huth wrote: > > On 08/09/15 07:15, David Gibson wrote: > ... > >> 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). > >=20 > > 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: > >=20 > > -device spapr-rng,backend=3Drng0,usekvm=3D0 > >=20 > > 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!). > >=20 > > 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. >=20 > I did some more tests, and I think I can get this working with one small > modification to spapr_vio.c: >=20 > diff --git a/hw/ppc/spapr_vio.c b/hw/ppc/spapr_vio.c > index c51eb8e..8e7f6b4 100644 > --- a/hw/ppc/spapr_vio.c > +++ b/hw/ppc/spapr_vio.c > @@ -99,6 +99,14 @@ static int vio_make_devnode(VIOsPAPRDevice *dev, > int vdevice_off, node_off, ret; > char *dt_name; >=20 > + if (!pc->dt_name) { > + ret =3D 0; > + if (pc->devnode) { > + ret =3D (pc->devnode)(dev, fdt, -1); > + } > + return ret; > + } > + > vdevice_off =3D fdt_path_offset(fdt, "/vdevice"); > if (vdevice_off < 0) { > return vdevice_off; >=20 > i.e. when the dt_name has not been set, the device won't be added to the > /vdevice device tree node. If that's acceptable, I'll continue with this > approach. A bit hacky. I think it would be preferable to build it under SysBus by default, like spapr-rtc. Properties can be set on the device using -global (or -set, but -global is easier). --=20 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 --/Uq4LBwYP4y1W6pO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV8V4zAAoJEGw4ysog2bOSUN0QALjGeYUlVDpRtMYMj2qzz1Ul Pu6ha8L907imFiwuXiN0jGFuopCnAp+21GrxgrcanA/DfrcOQH39Oph/ljlxtoKF Vhi57gxwMx2dK2cB5VBrWrSelCHXoVydHH1t43mSl+cVkW0EgVHtmn+fjvVxOmbc QLdGZrF9b2+BvsHSI7aEwvweiaXmHo8EI1fpsLTGrhOMnOzT2ZrV1my7KfikusMH YeJuBw3aln1viYrfzBIi0pbVcR+izU7OZ7ZsaLkaHuKYsiIyekDL8W8JuO1iDc6o W1ixZz9UdsK5ZbSs2IhsY1VpfUXucWceaJNfUYUVOqGPR05xKonqpsTGazq2tCMC OFqX+/pBjIgwhMPrvQzqN7kEehugBk7+64nOSqwJtUSMImAsi2s+1pLVAyn1y0yI GQs2+j6Bs+vV1dEYLx2MaFd5bkhF7TZK/LySiy/47wmi8KXV18wSPOgytppUj1cl U1A1d414TViZT4Ebga/HP2ZNVjcg7qSv3ra38qUqioyBpMZM1i3xkA3Ku+QGxYok /nH07CDeDxDqkNBLZ4H6ouvjsfF1xwMQtLhFdjjVBqpU4Z7YqMnofwSlM91lS0lY d2Vfkts2e2oiH2cCj+nWzQe9GuAiw3iq73n2MWZFyw8ZbbbNlSox850bfQz89/nk Ai4SHhR8TtdUS2Y90ZYD =oFhP -----END PGP SIGNATURE----- --/Uq4LBwYP4y1W6pO--