From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaCaq-0005if-4k for qemu-devel@nongnu.org; Thu, 10 Sep 2015 20:53:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaCam-0005qu-2Q for qemu-devel@nongnu.org; Thu, 10 Sep 2015 20:53:32 -0400 Date: Fri, 11 Sep 2015 10:46:57 +1000 From: David Gibson Message-ID: <20150911004657.GG11781@voom> References: <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> <20150910104051.GC11781@voom> <55F1719B.5070208@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RDS4xtyBfx+7DiaI" Content-Disposition: inline In-Reply-To: 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: Alexander Graf Cc: Thomas Huth , "armbru@redhat.com" , "qemu-devel@nongnu.org" , "michael@ellerman.id.au" , "qemu-ppc@nongnu.org" , "amit.shah@redhat.com" , Sam Bobroff --RDS4xtyBfx+7DiaI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 10, 2015 at 02:13:26PM +0200, Alexander Graf wrote: >=20 >=20 > > Am 10.09.2015 um 14:03 schrieb Thomas Huth : > >=20 > >> On 10/09/15 12:40, David Gibson wrote: > >>> 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, s= o I > >>>> also tried that instead, but then the rng device suddenly shows up u= nder > >>>> /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 sm= all > >>> modification to spapr_vio.c > > ... > >>> 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 t= his > >>> approach. > >>=20 > >> A bit hacky. > >>=20 > >> 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 > > If anyhow possible, I'd prefere to use "-device" for this instead, beca= use > >=20 > > a) it's easier to use for the user, for example you can simply use > > "-device spapr-rng,?" to get the list of properties - this > > does not seem to work with spapr-rtc (it has a "date" property > > which does not show up in the help text?) > >=20 > > b) unlike the rtc device which is always instantiated, the rng > > device is rather optional, so it is IMHO more intuitive if > > created via the -device option. > >=20 > > So I'd like to give it a try with the TYPE_VIO_SPAPR_DEVICE first ... if > > you then still don't like the patches at all, I can still rework them to > > use TYPE_SYS_BUS_DEVICE instead. >=20 > Please don't use sysbus. If the vio device approach turns ugly, > create a new spapr hcall bus instead. We should have had that from > the beginning really. Ok.. why? It's a system (pseudo-)device that doesn't have any common bus infrastructure with anything else. Isn't that what SysBus is for? --=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 --RDS4xtyBfx+7DiaI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV8iSBAAoJEGw4ysog2bOSTjEP/1HA6Z0G/gwMKKts5CYK6vyU 51LW5ssN8UTNitFAdYQL/l9pA9cnPTTvNFyl3ijxlLjdQneXk/8GlmLb2VxuYHUH KEvjn9lfCNlRuzH1zmJeh0sQigNxFcwFVK4I91CB+aiUl8xi4Xs1mXRwG9WDsDeK +D/AaJIvRuWsWpGYZBwTSgiCkTTdWI/29lInY7uY6onJDMJf9EAr+TMQnX4I1ISt dy/4+NeggFQgnYuJg4p8S316IFs1SU3cWc0R6gFG9VYLdHR14ifPbNZ7JFvduzrO C5V1BEgVc4tL+fCoBKrj5wpk6a3hK+BhaJS1jkfOCi/MmUkuXnnK5AZyTXf2eOWd e39rYmngsIOFkSWWQgxjkzaBNV2j2SjLI5ZjOFBDXKp4wynczAuq0zngP+HOtHZZ mv+Fq7xG076nddbHs3EbQM1x8Gv5mujCo0d0QuLyBrHxoYAPnVxabUnIJFXrEMAm CYqPG6UlLcepOIrLNnbrwEs/N9wuyA1Ln4VlGr/YITfyzUBFqqBac988W0d9hs5g maPRCgaxtJ7Sl96rCnboTuRnqzm7HCPz9Y51peXk0k9TzukePcLbsjPHIQ7mSiW+ smnNByyfr29W7EuHOPrgjUVrK+aiwsVGeqmSRE2mrVV/7DKVIyKhEZ4cjVRAiUDX n1KmFHdGCtB9nxZ6wgTM =MCNd -----END PGP SIGNATURE----- --RDS4xtyBfx+7DiaI--