Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/2] spapr: Add support for hwrng when available

[Thomas Huth <thuth@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]

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 <michael@ellerman.id.au>
>>>>>
>>>>> 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.
...
>> What if we set up another backend that just enables the hcall in KVM?
> 
> I think that's basically the right approach.
> 
> 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.
> 
> 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.
> 
> 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.

So I am currently not sure whether this is the right approach. Any
recommendations? Or shall I stick with the machine option?

 Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]