ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
/*
|
|
|
|
* QEMU sPAPR random number generator "device" for H_RANDOM hypercall
|
|
|
|
*
|
|
|
|
* Copyright 2015 Thomas Huth, Red Hat Inc.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License,
|
|
|
|
* or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
2016-01-26 21:16:58 +03:00
|
|
|
#include "qemu/osdep.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 11:01:28 +03:00
|
|
|
#include "qapi/error.h"
|
2016-01-19 23:51:44 +03:00
|
|
|
#include "qemu-common.h"
|
|
|
|
#include "cpu.h"
|
ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
#include "qemu/error-report.h"
|
|
|
|
#include "sysemu/sysemu.h"
|
|
|
|
#include "sysemu/device_tree.h"
|
|
|
|
#include "sysemu/rng.h"
|
|
|
|
#include "hw/ppc/spapr.h"
|
|
|
|
#include "kvm_ppc.h"
|
|
|
|
|
|
|
|
#define SPAPR_RNG(obj) \
|
|
|
|
OBJECT_CHECK(sPAPRRngState, (obj), TYPE_SPAPR_RNG)
|
|
|
|
|
|
|
|
struct sPAPRRngState {
|
|
|
|
/*< private >*/
|
|
|
|
DeviceState ds;
|
|
|
|
RngBackend *backend;
|
|
|
|
bool use_kvm;
|
|
|
|
};
|
|
|
|
typedef struct sPAPRRngState sPAPRRngState;
|
|
|
|
|
|
|
|
struct HRandomData {
|
|
|
|
QemuSemaphore sem;
|
|
|
|
union {
|
|
|
|
uint64_t v64;
|
|
|
|
uint8_t v8[8];
|
|
|
|
} val;
|
|
|
|
int received;
|
|
|
|
};
|
|
|
|
typedef struct HRandomData HRandomData;
|
|
|
|
|
|
|
|
/* Callback function for the RngBackend */
|
|
|
|
static void random_recv(void *dest, const void *src, size_t size)
|
|
|
|
{
|
|
|
|
HRandomData *hrdp = dest;
|
|
|
|
|
|
|
|
if (src && size > 0) {
|
|
|
|
assert(size + hrdp->received <= sizeof(hrdp->val.v8));
|
|
|
|
memcpy(&hrdp->val.v8[hrdp->received], src, size);
|
|
|
|
hrdp->received += size;
|
|
|
|
}
|
|
|
|
|
|
|
|
qemu_sem_post(&hrdp->sem);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Handler for the H_RANDOM hypercall */
|
|
|
|
static target_ulong h_random(PowerPCCPU *cpu, sPAPRMachineState *spapr,
|
|
|
|
target_ulong opcode, target_ulong *args)
|
|
|
|
{
|
|
|
|
sPAPRRngState *rngstate;
|
|
|
|
HRandomData hrdata;
|
|
|
|
|
|
|
|
rngstate = SPAPR_RNG(object_resolve_path_type("", TYPE_SPAPR_RNG, NULL));
|
|
|
|
|
|
|
|
if (!rngstate || !rngstate->backend) {
|
|
|
|
return H_HARDWARE;
|
|
|
|
}
|
|
|
|
|
|
|
|
qemu_sem_init(&hrdata.sem, 0);
|
|
|
|
hrdata.val.v64 = 0;
|
|
|
|
hrdata.received = 0;
|
|
|
|
|
|
|
|
while (hrdata.received < 8) {
|
|
|
|
rng_backend_request_entropy(rngstate->backend, 8 - hrdata.received,
|
|
|
|
random_recv, &hrdata);
|
2016-03-11 21:48:47 +03:00
|
|
|
qemu_mutex_unlock_iothread();
|
ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
qemu_sem_wait(&hrdata.sem);
|
2016-03-11 21:48:47 +03:00
|
|
|
qemu_mutex_lock_iothread();
|
ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
qemu_sem_destroy(&hrdata.sem);
|
|
|
|
args[0] = hrdata.val.v64;
|
|
|
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_rng_instance_init(Object *obj)
|
|
|
|
{
|
|
|
|
if (object_resolve_path_type("", TYPE_SPAPR_RNG, NULL) != NULL) {
|
|
|
|
error_report("spapr-rng can not be instantiated twice!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
object_property_set_description(obj, "rng",
|
|
|
|
"ID of the random number generator backend",
|
|
|
|
NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void spapr_rng_realize(DeviceState *dev, Error **errp)
|
|
|
|
{
|
|
|
|
|
|
|
|
sPAPRRngState *rngstate = SPAPR_RNG(dev);
|
|
|
|
|
|
|
|
if (rngstate->use_kvm) {
|
|
|
|
if (kvmppc_enable_hwrng() == 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* If user specified both, use-kvm and a backend, we fall back to
|
|
|
|
* the backend now. If not, provide an appropriate error message.
|
|
|
|
*/
|
|
|
|
if (!rngstate->backend) {
|
|
|
|
error_setg(errp, "Could not initialize in-kernel H_RANDOM call!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rngstate->backend) {
|
|
|
|
spapr_register_hypercall(H_RANDOM, h_random);
|
|
|
|
} else {
|
|
|
|
error_setg(errp, "spapr-rng needs an RNG backend!");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static Property spapr_rng_properties[] = {
|
|
|
|
DEFINE_PROP_BOOL("use-kvm", sPAPRRngState, use_kvm, false),
|
2017-07-14 05:15:09 +03:00
|
|
|
DEFINE_PROP_LINK("rng", sPAPRRngState, backend, TYPE_RNG_BACKEND,
|
|
|
|
RngBackend *),
|
ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
DEFINE_PROP_END_OF_LIST(),
|
|
|
|
};
|
|
|
|
|
|
|
|
static void spapr_rng_class_init(ObjectClass *oc, void *data)
|
|
|
|
{
|
|
|
|
DeviceClass *dc = DEVICE_CLASS(oc);
|
|
|
|
|
|
|
|
dc->realize = spapr_rng_realize;
|
|
|
|
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
|
|
|
|
dc->props = spapr_rng_properties;
|
2016-02-25 14:08:00 +03:00
|
|
|
dc->hotpluggable = false;
|
ppc/spapr: Implement H_RANDOM hypercall in QEMU
The PAPR interface defines a hypercall to pass high-quality
hardware generated random numbers to guests. Recent kernels can
already provide this hypercall to the guest if the right hardware
random number generator is available. But in case the user wants
to use another source like EGD, or QEMU is running with an older
kernel, we should also have this call in QEMU, so that guests that
do not support virtio-rng yet can get good random numbers, too.
This patch now adds a new pseudo-device to QEMU that either
directly provides this hypercall to the guest or is able to
enable the in-kernel hypercall if available. The in-kernel
hypercall can be enabled with the use-kvm property, e.g.:
qemu-system-ppc64 -device spapr-rng,use-kvm=true
For handling the hypercall in QEMU instead, a "RngBackend" is
required since the hypercall should provide "good" random data
instead of pseudo-random (like from a "simple" library function
like rand() or g_random_int()). Since there are multiple RngBackends
available, the user must select an appropriate back-end via the
"rng" property of the device, e.g.:
qemu-system-ppc64 -object rng-random,filename=/dev/hwrng,id=gid0 \
-device spapr-rng,rng=gid0 ...
See http://wiki.qemu-project.org/Features-Done/VirtIORNG for
other example of specifying RngBackends.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-17 11:49:41 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static const TypeInfo spapr_rng_info = {
|
|
|
|
.name = TYPE_SPAPR_RNG,
|
|
|
|
.parent = TYPE_DEVICE,
|
|
|
|
.instance_size = sizeof(sPAPRRngState),
|
|
|
|
.instance_init = spapr_rng_instance_init,
|
|
|
|
.class_init = spapr_rng_class_init,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void spapr_rng_register_type(void)
|
|
|
|
{
|
|
|
|
type_register_static(&spapr_rng_info);
|
|
|
|
}
|
|
|
|
type_init(spapr_rng_register_type)
|