Commit Message

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>
---
hw/ppc/spapr.c | 16 ++++++++++++++++
include/hw/ppc/spapr.h | 1 +
linux-headers/linux/kvm.h | 1 +
target-ppc/kvm.c | 5 +++++
target-ppc/kvm_ppc.h | 5 +++++
5 files changed, 28 insertions(+)

Comments

On 26.09.2013, at 08:37, Michael Ellerman wrote:
> 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>
Please implement this 100% without KVM first, then if we end up running into performance bottlenecks we can always add KVM acceleration.
Also, please make sure to CC qemu-ppc@nongnu.org on PPC patches :).
Alex

On Thu, 2013-09-26 at 13:06 +0200, Alexander Graf wrote:
> On 26.09.2013, at 08:37, Michael Ellerman wrote:> > > 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>> > Please implement this 100% without KVM first, then if we end up running into performance bottlenecks we can always add KVM acceleration.
So have the host kernel read from the hwrng, export it to userspace via
a char device, which is then read by qemu, which then copies it back
into the host kernel, which can then give it to the guest.
Or from the guest perspective, instead of a cheap switch to host real
mode and back - a full switch to kernel virtual, then to user, back to
kernel, back to user, back to kernel, back to guest.
Frankly I can't see why that is a superior option?
> Also, please make sure to CC qemu-ppc@nongnu.org on PPC patches :).
Sorry, didn't realise there was one, will add it in future.
cheers

Il 27/09/2013 10:36, Michael Ellerman ha scritto:
> So have the host kernel read from the hwrng, export it to userspace via> a char device, which is then read by qemu, which then copies it back> into the host kernel, which can then give it to the guest.> > Or from the guest perspective, instead of a cheap switch to host real> mode and back - a full switch to kernel virtual, then to user, back to> kernel, back to user, back to kernel, back to guest.> > Frankly I can't see why that is a superior option?
Because this is not a fast path at all. Doing things in QEMU lets
people test and configure the paravirtualized hwrng even if they do not
have a hwrng in the host, and even if they are running with emulation
(TCG) instead of KVM.
But as I mentioned in the kernel thread, perhaps you do not need the
hypercall at all if virtio-rng is enough (it should be for Linux guests).
Paolo