From: Thomas Huth <thuth@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: armbru@redhat.com, qemu-devel@nongnu.org, michael@ellerman.id.au,
qemu-ppc@nongnu.org, amit.shah@redhat.com,
Sam Bobroff <sam.bobroff@au1.ibm.com>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/2] spapr: Add support for hwrng when available
Date: Thu, 10 Sep 2015 14:03:39 +0200 [thread overview]
Message-ID: <55F1719B.5070208@redhat.com> (raw)
In-Reply-To: <20150910104051.GC11781@voom>
[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]
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).
>>>
>>> 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=rng0,usekvm=0
>>>
>>> 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.
>>
>> I did some more tests, and I think I can get this working with one small
>> 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 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).
If anyhow possible, I'd prefere to use "-device" for this instead, because
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?)
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.
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.
Thomas
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2015-09-10 12:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-31 18:46 [Qemu-devel] [PATCH v2 0/2] ppc/spapr_hcall: Implement H_RANDOM hypercall Thomas Huth
2015-08-31 18:46 ` [Qemu-devel] [PATCH v2 1/2] spapr: Add support for hwrng when available Thomas Huth
2015-09-01 0:38 ` David Gibson
2015-09-01 10:53 ` Thomas Huth
2015-09-08 5:03 ` [Qemu-devel] [Qemu-ppc] " Sam Bobroff
2015-09-08 5:15 ` David Gibson
2015-09-09 21:10 ` Thomas Huth
2015-09-10 7:33 ` Thomas Huth
2015-09-10 10:40 ` David Gibson
2015-09-10 12:03 ` Thomas Huth [this message]
2015-09-10 12:13 ` Alexander Graf
2015-09-11 0:46 ` David Gibson
2015-09-11 9:43 ` Alexander Graf
2015-09-14 2:27 ` David Gibson
2015-09-14 7:36 ` Alexander Graf
2015-09-11 0:45 ` David Gibson
2015-09-11 7:30 ` Thomas Huth
2015-09-14 2:25 ` David Gibson
2015-09-08 5:38 ` Thomas Huth
2015-09-09 0:54 ` Sam Bobroff
2015-09-10 12:06 ` Greg Kurz
2015-09-09 14:09 ` [Qemu-devel] " Greg Kurz
2015-08-31 18:46 ` [Qemu-devel] [PATCH v2 2/2] ppc/spapr_hcall: Implement H_RANDOM hypercall in QEMU Thomas Huth
2015-09-01 0:47 ` David Gibson
2015-09-01 11:03 ` Thomas Huth
2015-09-07 15:05 ` Thomas Huth
2015-09-08 1:14 ` David Gibson
2015-09-02 5:34 ` Amit Shah
2015-09-02 7:48 ` David Gibson
2015-09-02 8:58 ` Thomas Huth
2015-09-02 10:06 ` Amit Shah
2015-09-02 10:02 ` Amit Shah
2015-09-03 1:21 ` Michael Ellerman
2015-09-03 2:17 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F1719B.5070208@redhat.com \
--to=thuth@redhat.com \
--cc=amit.shah@redhat.com \
--cc=armbru@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=michael@ellerman.id.au \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=sam.bobroff@au1.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).