| Message ID | 1441046762-5788-2-git-send-email-thuth@redhat.com |
|---|---|
| State | New |
| Headers | show |
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. > > The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG > capability. If this is detected we add the appropriate device tree bits > to advertise the presence of the hwrng to the guest kernel. > > Signed-off-by: Michael Ellerman <michael@ellerman.id.au> > [thuth: Refreshed patch so it applies to QEMU master branch] > Signed-off-by: Thomas Huth <thuth@redhat.com> So, I'm confused by one thing. I thought new kernel handled hcalls were supposed to be disabled by default, but I don't see any calls to kvmppc_enable_hcall() to turn on H_RANDOM. > --- > hw/ppc/spapr.c | 16 ++++++++++++++++ > include/hw/ppc/spapr.h | 1 + > target-ppc/kvm.c | 5 +++++ > target-ppc/kvm_ppc.h | 5 +++++ > 4 files changed, 27 insertions(+) > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index bf0c64f..bc3a112 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -466,6 +466,22 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base, > > _FDT((fdt_end_node(fdt))); > > + if (kvmppc_hwrng_present()) { > + _FDT(fdt_begin_node(fdt, "ibm,platform-facilities")); > + > + _FDT(fdt_property_string(fdt, "name", "ibm,platform-facilities")); Also, "name" properties don't need to be set in flattened trees - that's implicit in the node name itself. > + _FDT(fdt_property_string(fdt, "device_type", > + "ibm,platform-facilities")); > + _FDT(fdt_property_cell(fdt, "#address-cells", 0x1)); > + _FDT(fdt_property_cell(fdt, "#size-cells", 0x0)); > + _FDT(fdt_begin_node(fdt, "ibm,random-v1")); > + _FDT(fdt_property_string(fdt, "name", "ibm,random-v1")); > + _FDT(fdt_property_string(fdt, "compatible", "ibm,random")); > + _FDT((fdt_end_node(fdt))); > + } > + > + _FDT((fdt_end_node(fdt))); > + > /* event-sources */ > spapr_events_fdt_skel(fdt, epow_irq); > > diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h > index 91a61ab..ab8906f 100644 > --- a/include/hw/ppc/spapr.h > +++ b/include/hw/ppc/spapr.h > @@ -331,6 +331,7 @@ struct sPAPRMachineState { > #define H_SET_MPP 0x2D0 > #define H_GET_MPP 0x2D4 > #define H_XIRR_X 0x2FC > +#define H_RANDOM 0x300 > #define H_SET_MODE 0x31C > #define MAX_HCALL_OPCODE H_SET_MODE > > diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c > index 110436d..7317f8f 100644 > --- a/target-ppc/kvm.c > +++ b/target-ppc/kvm.c > @@ -2484,3 +2484,8 @@ int kvm_arch_msi_data_to_gsi(uint32_t data) > { > return data & 0xffff; > } > + > +bool kvmppc_hwrng_present(void) > +{ > + return kvm_enabled() && kvm_check_extension(kvm_state, KVM_CAP_PPC_HWRNG); > +} > diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h > index 4d30e27..62ff601 100644 > --- a/target-ppc/kvm_ppc.h > +++ b/target-ppc/kvm_ppc.h > @@ -55,6 +55,7 @@ void kvmppc_hash64_free_pteg(uint64_t token); > void kvmppc_hash64_write_pte(CPUPPCState *env, target_ulong pte_index, > target_ulong pte0, target_ulong pte1); > bool kvmppc_has_cap_fixup_hcalls(void); > +bool kvmppc_hwrng_present(void); > > #else > > @@ -248,6 +249,10 @@ static inline bool kvmppc_has_cap_fixup_hcalls(void) > abort(); > } > > +static inline bool kvmppc_hwrng_present(void) > +{ > + return false; > +} > #endif > > #ifndef CONFIG_KVM
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. >> >> The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG >> capability. If this is detected we add the appropriate device tree bits >> to advertise the presence of the hwrng to the guest kernel. >> >> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> >> [thuth: Refreshed patch so it applies to QEMU master branch] >> Signed-off-by: Thomas Huth <thuth@redhat.com> > > So, I'm confused by one thing. > > I thought new kernel handled hcalls were supposed to be disabled by > default, but I don't see any calls to kvmppc_enable_hcall() to turn on > H_RANDOM. Michael's patch was from 2013, the kvmppc_enable_hcall() stuff seems to be from 2014 ... so the enablement is likely missing in this patch, indeed. I didn't test the in-kernel hypercall yet, just my QEMU implementation so far, that's why I did not notice this yet. Michael, do you want to rework your patch? Or shall I add an additional enablement patch to my queue? Thomas
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. > >> > >> The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG > >> capability. If this is detected we add the appropriate device tree bits > >> to advertise the presence of the hwrng to the guest kernel. > >> > >> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> > >> [thuth: Refreshed patch so it applies to QEMU master branch] > >> Signed-off-by: Thomas Huth <thuth@redhat.com> > > > > So, I'm confused by one thing. > > > > I thought new kernel handled hcalls were supposed to be disabled by > > default, but I don't see any calls to kvmppc_enable_hcall() to turn on > > H_RANDOM. > > Michael's patch was from 2013, the kvmppc_enable_hcall() stuff seems to > be from 2014 ... so the enablement is likely missing in this patch, > indeed. I didn't test the in-kernel hypercall yet, just my QEMU > implementation so far, that's why I did not notice this yet. > > Michael, do you want to rework your patch? Or shall I add an additional > enablement patch to my queue? If I recall correctly, it's specifically not enabled: there was quite a lot of discussion about it when Michael posted the patches and I think the consensus was that it should only be enabled by QEMU, and only if the user could decide if it was used or not. What if we set up another backend that just enables the hcall in KVM? This would answer the question about what to do if both are available as well: just do only what the user has asked for. (But I'm not sure what the default behaviour should be if the user doesn't specify anything.) (Oh also: I have tested the in-kernel hcall using a QEMU modified to enable it and it seems to work :-) Cheers, Sam.
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. > > >> > > >> The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG > > >> capability. If this is detected we add the appropriate device tree bits > > >> to advertise the presence of the hwrng to the guest kernel. > > >> > > >> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> > > >> [thuth: Refreshed patch so it applies to QEMU master branch] > > >> Signed-off-by: Thomas Huth <thuth@redhat.com> > > > > > > So, I'm confused by one thing. > > > > > > I thought new kernel handled hcalls were supposed to be disabled by > > > default, but I don't see any calls to kvmppc_enable_hcall() to turn on > > > H_RANDOM. > > > > Michael's patch was from 2013, the kvmppc_enable_hcall() stuff seems to > > be from 2014 ... so the enablement is likely missing in this patch, > > indeed. I didn't test the in-kernel hypercall yet, just my QEMU > > implementation so far, that's why I did not notice this yet. > > > > Michael, do you want to rework your patch? Or shall I add an additional > > enablement patch to my queue? > > If I recall correctly, it's specifically not enabled: there was quite a lot of > discussion about it when Michael posted the patches and I think the consensus > was that it should only be enabled by QEMU, and only if the user could decide > if it was used or not. > > 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).
On 08/09/15 07:03, 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. >>>> >>>> The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG >>>> capability. If this is detected we add the appropriate device tree bits >>>> to advertise the presence of the hwrng to the guest kernel. >>>> >>>> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> >>>> [thuth: Refreshed patch so it applies to QEMU master branch] >>>> Signed-off-by: Thomas Huth <thuth@redhat.com> >>> >>> So, I'm confused by one thing. >>> >>> I thought new kernel handled hcalls were supposed to be disabled by >>> default, but I don't see any calls to kvmppc_enable_hcall() to turn on >>> H_RANDOM. >> >> Michael's patch was from 2013, the kvmppc_enable_hcall() stuff seems to >> be from 2014 ... so the enablement is likely missing in this patch, >> indeed. I didn't test the in-kernel hypercall yet, just my QEMU >> implementation so far, that's why I did not notice this yet. >> >> Michael, do you want to rework your patch? Or shall I add an additional >> enablement patch to my queue? > > If I recall correctly, it's specifically not enabled: there was quite a lot of > discussion about it when Michael posted the patches and I think the consensus > was that it should only be enabled by QEMU, and only if the user could decide > if it was used or not. Can you find this discussion in a mailing list archive somewhere? The only discussions I've found are basically these: http://lists.nongnu.org/archive/html/qemu-devel/2013-09/msg04233.html https://lkml.org/lkml/fancy/2013/10/1/49 ... and there it was only discussed that the call should be implemented in QEMU, too. I did not spot any discussion about making it switchable for the user? Thomas
On Tue, Sep 08, 2015 at 07:38:12AM +0200, Thomas Huth wrote: > On 08/09/15 07:03, 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. > >>>> > >>>> The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG > >>>> capability. If this is detected we add the appropriate device tree bits > >>>> to advertise the presence of the hwrng to the guest kernel. > >>>> > >>>> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> > >>>> [thuth: Refreshed patch so it applies to QEMU master branch] > >>>> Signed-off-by: Thomas Huth <thuth@redhat.com> > >>> > >>> So, I'm confused by one thing. > >>> > >>> I thought new kernel handled hcalls were supposed to be disabled by > >>> default, but I don't see any calls to kvmppc_enable_hcall() to turn on > >>> H_RANDOM. > >> > >> Michael's patch was from 2013, the kvmppc_enable_hcall() stuff seems to > >> be from 2014 ... so the enablement is likely missing in this patch, > >> indeed. I didn't test the in-kernel hypercall yet, just my QEMU > >> implementation so far, that's why I did not notice this yet. > >> > >> Michael, do you want to rework your patch? Or shall I add an additional > >> enablement patch to my queue? > > > > If I recall correctly, it's specifically not enabled: there was quite a lot of > > discussion about it when Michael posted the patches and I think the consensus > > was that it should only be enabled by QEMU, and only if the user could decide > > if it was used or not. > > Can you find this discussion in a mailing list archive somewhere? The > only discussions I've found are basically these: > > http://lists.nongnu.org/archive/html/qemu-devel/2013-09/msg04233.html > https://lkml.org/lkml/fancy/2013/10/1/49 > > ... and there it was only discussed that the call should be implemented > in QEMU, too. I did not spot any discussion about making it switchable > for the user? Sorry that part wasn't very well worded: I was trying to say that QEMU's configuration should be able to choose how H_RANDOM handled, rather than having it automatically choose based on what was available in KVM and that's what we're considering now anyway. (See David's comment elsewhere in this thread.) Sam.
On Mon, 31 Aug 2015 20:46:01 +0200 Thomas Huth <thuth@redhat.com> 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. > > The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG > capability. If this is detected we add the appropriate device tree bits > to advertise the presence of the hwrng to the guest kernel. > > Signed-off-by: Michael Ellerman <michael@ellerman.id.au> > [thuth: Refreshed patch so it applies to QEMU master branch] > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > hw/ppc/spapr.c | 16 ++++++++++++++++ > include/hw/ppc/spapr.h | 1 + > target-ppc/kvm.c | 5 +++++ > target-ppc/kvm_ppc.h | 5 +++++ > 4 files changed, 27 insertions(+) > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index bf0c64f..bc3a112 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -466,6 +466,22 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base, > > _FDT((fdt_end_node(fdt))); > > + if (kvmppc_hwrng_present()) { > + _FDT(fdt_begin_node(fdt, "ibm,platform-facilities")); > + > + _FDT(fdt_property_string(fdt, "name", "ibm,platform-facilities")); > + _FDT(fdt_property_string(fdt, "device_type", > + "ibm,platform-facilities")); > + _FDT(fdt_property_cell(fdt, "#address-cells", 0x1)); > + _FDT(fdt_property_cell(fdt, "#size-cells", 0x0)); > + _FDT(fdt_begin_node(fdt, "ibm,random-v1")); > + _FDT(fdt_property_string(fdt, "name", "ibm,random-v1")); > + _FDT(fdt_property_string(fdt, "compatible", "ibm,random")); > + _FDT((fdt_end_node(fdt))); > + } > + > + _FDT((fdt_end_node(fdt))); > + > /* event-sources */ > spapr_events_fdt_skel(fdt, epow_irq); > > diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h > index 91a61ab..ab8906f 100644 > --- a/include/hw/ppc/spapr.h > +++ b/include/hw/ppc/spapr.h > @@ -331,6 +331,7 @@ struct sPAPRMachineState { > #define H_SET_MPP 0x2D0 > #define H_GET_MPP 0x2D4 > #define H_XIRR_X 0x2FC > +#define H_RANDOM 0x300 > #define H_SET_MODE 0x31C > #define MAX_HCALL_OPCODE H_SET_MODE > H_RANDOM isn't used in this patch, I believe the above hunk belongs to patch 2/2 actually. Cheers. -- Greg > diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c > index 110436d..7317f8f 100644 > --- a/target-ppc/kvm.c > +++ b/target-ppc/kvm.c > @@ -2484,3 +2484,8 @@ int kvm_arch_msi_data_to_gsi(uint32_t data) > { > return data & 0xffff; > } > + > +bool kvmppc_hwrng_present(void) > +{ > + return kvm_enabled() && kvm_check_extension(kvm_state, KVM_CAP_PPC_HWRNG); > +} > diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h > index 4d30e27..62ff601 100644 > --- a/target-ppc/kvm_ppc.h > +++ b/target-ppc/kvm_ppc.h > @@ -55,6 +55,7 @@ void kvmppc_hash64_free_pteg(uint64_t token); > void kvmppc_hash64_write_pte(CPUPPCState *env, target_ulong pte_index, > target_ulong pte0, target_ulong pte1); > bool kvmppc_has_cap_fixup_hcalls(void); > +bool kvmppc_hwrng_present(void); > > #else > > @@ -248,6 +249,10 @@ static inline bool kvmppc_has_cap_fixup_hcalls(void) > abort(); > } > > +static inline bool kvmppc_hwrng_present(void) > +{ > + return false; > +} > #endif > > #ifndef CONFIG_KVM
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
On Wed, 9 Sep 2015 10:54:20 +1000 Sam Bobroff <sam.bobroff@au1.ibm.com> wrote: > On Tue, Sep 08, 2015 at 07:38:12AM +0200, Thomas Huth wrote: > > On 08/09/15 07:03, 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. > > >>>> > > >>>> The kernel advertises the presence of a hwrng with the KVM_CAP_PPC_HWRNG > > >>>> capability. If this is detected we add the appropriate device tree bits > > >>>> to advertise the presence of the hwrng to the guest kernel. > > >>>> > > >>>> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> > > >>>> [thuth: Refreshed patch so it applies to QEMU master branch] > > >>>> Signed-off-by: Thomas Huth <thuth@redhat.com> > > >>> > > >>> So, I'm confused by one thing. > > >>> > > >>> I thought new kernel handled hcalls were supposed to be disabled by > > >>> default, but I don't see any calls to kvmppc_enable_hcall() to turn on > > >>> H_RANDOM. > > >> > > >> Michael's patch was from 2013, the kvmppc_enable_hcall() stuff seems to > > >> be from 2014 ... so the enablement is likely missing in this patch, > > >> indeed. I didn't test the in-kernel hypercall yet, just my QEMU > > >> implementation so far, that's why I did not notice this yet. > > >> > > >> Michael, do you want to rework your patch? Or shall I add an additional > > >> enablement patch to my queue? > > > > > > If I recall correctly, it's specifically not enabled: there was quite a lot of > > > discussion about it when Michael posted the patches and I think the consensus > > > was that it should only be enabled by QEMU, and only if the user could decide > > > if it was used or not. > > > > Can you find this discussion in a mailing list archive somewhere? The > > only discussions I've found are basically these: > > > > http://lists.nongnu.org/archive/html/qemu-devel/2013-09/msg04233.html > > https://lkml.org/lkml/fancy/2013/10/1/49 > > > > ... and there it was only discussed that the call should be implemented > > in QEMU, too. I did not spot any discussion about making it switchable > > for the user? > > Sorry that part wasn't very well worded: I was trying to say that QEMU's > configuration should be able to choose how H_RANDOM handled, rather than having > it automatically choose based on what was available in KVM and that's what > we're considering now anyway. (See David's comment elsewhere in this thread.) > > Sam. > > In this case, this patch isn't appropriate anymore: QEMU would advertise support for "ibm,random-v1" but guests would be returned H_FUNCTION. The DT bits should be in a later patch, after H_RANDOM is plugged in (either KVM or QEMU). Cheers. -- Greg
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index bf0c64f..bc3a112 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -466,6 +466,22 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base, _FDT((fdt_end_node(fdt))); + if (kvmppc_hwrng_present()) { + _FDT(fdt_begin_node(fdt, "ibm,platform-facilities")); + + _FDT(fdt_property_string(fdt, "name", "ibm,platform-facilities")); + _FDT(fdt_property_string(fdt, "device_type", + "ibm,platform-facilities")); + _FDT(fdt_property_cell(fdt, "#address-cells", 0x1)); + _FDT(fdt_property_cell(fdt, "#size-cells", 0x0)); + _FDT(fdt_begin_node(fdt, "ibm,random-v1")); + _FDT(fdt_property_string(fdt, "name", "ibm,random-v1")); + _FDT(fdt_property_string(fdt, "compatible", "ibm,random")); + _FDT((fdt_end_node(fdt))); + } + + _FDT((fdt_end_node(fdt))); + /* event-sources */ spapr_events_fdt_skel(fdt, epow_irq); diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h index 91a61ab..ab8906f 100644 --- a/include/hw/ppc/spapr.h +++ b/include/hw/ppc/spapr.h @@ -331,6 +331,7 @@ struct sPAPRMachineState { #define H_SET_MPP 0x2D0 #define H_GET_MPP 0x2D4 #define H_XIRR_X 0x2FC +#define H_RANDOM 0x300 #define H_SET_MODE 0x31C #define MAX_HCALL_OPCODE H_SET_MODE diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c index 110436d..7317f8f 100644 --- a/target-ppc/kvm.c +++ b/target-ppc/kvm.c @@ -2484,3 +2484,8 @@ int kvm_arch_msi_data_to_gsi(uint32_t data) { return data & 0xffff; } + +bool kvmppc_hwrng_present(void) +{ + return kvm_enabled() && kvm_check_extension(kvm_state, KVM_CAP_PPC_HWRNG); +} diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h index 4d30e27..62ff601 100644 --- a/target-ppc/kvm_ppc.h +++ b/target-ppc/kvm_ppc.h @@ -55,6 +55,7 @@ void kvmppc_hash64_free_pteg(uint64_t token); void kvmppc_hash64_write_pte(CPUPPCState *env, target_ulong pte_index, target_ulong pte0, target_ulong pte1); bool kvmppc_has_cap_fixup_hcalls(void); +bool kvmppc_hwrng_present(void); #else @@ -248,6 +249,10 @@ static inline bool kvmppc_has_cap_fixup_hcalls(void) abort(); } +static inline bool kvmppc_hwrng_present(void) +{ + return false; +} #endif #ifndef CONFIG_KVM