virtio-rng: hardware random number generator device
cover virtio-rng: hardware random number generator device
Hello,
Reviving this series last sent by Anthony to the list. The differences are minimal from the time Anthony sent, just rebasing to the current tree and fixing a couple of minor bugs.
I've not really looked in detail at the object patches -- mostly just concerned about the device itself.
Please review and apply if appropriate.
Changes from last submission:
- Fix a few typos/whitespaces in rng.h
- Switch to virtqueue_get_avail_bytes(): helps remove the savevm/loadvm complexities and provides a cleaner interface
- Remove the older qevent hunks that got left behind
- Rebase to master
- Bugfix: rng_backend_request_entropy() in chr_read() should pass len, not size
- Do not request for more entropy in chr_read() once the current request is served; there are other ways this notification will go out.
Amit Shah (1):
virtio-rng: hardware random number generator device
Anthony Liguori (7):
object: add object_property_add_bool (v2)
qdev: add realized property and make adding child bus implied by
realize
vl: add -object option to create QOM objects from the command line
vl: add -late-object to create QOM objects after machine init
rng: add RndBackend abstract object class
rng-urandom: add an RNG backend that uses /dev/urandom
rng-egd: introduce EGD compliant RNG backend
Makefile.objs | 2 + backends/Makefile.objs | 1 + backends/rng-egd.c | 215 ++++++++++++++++++++++++++++++++++++++++++++++++ backends/rng-urandom.c | 144 ++++++++++++++++++++++++++++++++ backends/rng.c | 93 +++++++++++++++++++++ hw/Makefile.objs | 1 + hw/pci.h | 1 + hw/qdev.c | 36 ++++++++- hw/s390-virtio-bus.c | 37 ++++++++ hw/s390-virtio-bus.h | 2 + hw/virtio-pci.c | 60 +++++++++++++ hw/virtio-pci.h | 2 + hw/virtio-rng.c | 149 +++++++++++++++++++++++++++++++++ hw/virtio-rng.h | 24 ++++++ hw/virtio.h | 3 + include/qemu/object.h | 16 ++++ include/qemu/rng.h | 93 +++++++++++++++++++++ qemu-config.c | 20 +++++ qemu-options.hx | 20 +++++ qom/object.c | 56 +++++++++++++ vl.c | 62 ++++++++++++++ 21 files changed, 1036 insertions(+), 1 deletions(-) create mode 100644 backends/Makefile.objs create mode 100644 backends/rng-egd.c create mode 100644 backends/rng-urandom.c create mode 100644 backends/rng.c create mode 100644 hw/virtio-rng.c create mode 100644 hw/virtio-rng.h create mode 100644 include/qemu/rng.h
Signature · 1 line
1.7.7.6
PATCH 1/8 object: add object_property_add_bool (v2)
From: Anthony Liguori <[email protected]>
--- include/qemu/object.h | 16 ++++++++++++++ qom/object.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 72 insertions(+), 0 deletions(-)
include/qemu/object.h +16 -0
@@ -947,6 +947,22 @@ void object_property_add_str(Object *obj, const char *name, struct Error **errp);/** +* object_property_add_bool: +* @obj: the object to add a property to +* @name: the name of the property +* @get: the getter or NULL if the property is write-only. +* @set: the setter or NULL if the property is read-only +* @errp: if an error occurs, a pointer to an area to store the error +* +* Add a bool property using getters/setters. This function will add a +* property of type 'bool'. +*/ +void object_property_add_bool (Object *obj,const char *name, +bool (*get)(Object *,struct Error **), +void (*set)(Object *,bool ,struct Error **), +struct Error **errp); + +/** * object_child_foreach: * @obj: the object whose children will be navigated * @fn: the iterator function to be called
qom/object.c +56 -0
62 lines not on this page · raw message
Signature · 1 line
1.7.7.6
PATCH 2/8 qdev: add realized property and make adding child bus implied by realize
In reply to Amit ShahFrom: Anthony Liguori <[email protected]>
--- hw/qdev.c | 36 +++++++++++++++++++++++++++++++++++- 1 files changed, 35 insertions(+), 1 deletions(-)
hw/qdev.c +35 -1
@@ -95,7 +95,6 @@ static void bus_add_child(BusState *bus, DeviceState *child)void qdev_set_parent_bus (DeviceState *dev,BusState *bus) { dev->parent_bus = bus; -bus_add_child (bus, dev); }/* Create a new device. This only initializes the device state structure
@@ -151,6 +150,10 @@ int qdev_init(DeviceState *dev)assert (dev->state ==DEV_STATE_CREATED ); +if (dev->parent_bus) { +bus_add_child (dev->parent_bus, dev); + } + rc = dc->init (dev);if (rc <0 ) {qdev_free (dev);
@@ -654,6 +657,33 @@ void qdev_property_add_static(DeviceState *dev, Property *prop,assert_no_error (local_err); } +static bool qdev_prop_get_realized (Object *obj,Error **errp) +{ +DeviceState *dev =DEVICE (obj); + +return (dev->state ==DEV_STATE_INITIALIZED ); +} + +static void qdev_prop_set_realized (Object *obj,bool value,Error **errp) +{ +DeviceState *dev =DEVICE (obj); +bool realized = (dev->state ==DEV_STATE_INITIALIZED ); + +if (realized == value) { +return ; + } + +if (realized && !value) { +error_set (errp,QERR_PERMISSION_DENIED ); +return ; + } + +if (qdev_init (dev) <0 ) { +error_set (errp,QERR_DEVICE_INIT_FAILED ,"" ); +return ; + } +} +static void device_initfn (Object *obj) {DeviceState *dev =DEVICE (obj);
@@ -678,6 +708,10 @@ static void device_initfn(Object *obj) }while (class !=object_class_by_name (TYPE_DEVICE ));qdev_prop_set_globals (dev); +object_property_add_bool (obj,"realized" , + qdev_prop_get_realized, qdev_prop_set_realized, +NULL ); +object_property_add_link (OBJECT (dev),"parent_bus" ,TYPE_BUS , (Object **)&dev->parent_bus,NULL ); }
Signature · 1 line
1.7.7.6
PATCH 3/8 vl: add -object option to create QOM objects from the command line
In reply to Amit ShahFrom: Anthony Liguori <[email protected]>
This will create a new QOM object in the '/objects' path. Note that properties are set in order which allows for simple objects to be initialized entirely with this option and then realized.
This option is roughly equivalent to -device but for things that are not devices.
--- qemu-config.c | 10 ++++++++++ qemu-options.hx | 8 ++++++++ vl.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 72 insertions(+), 0 deletions(-)
qemu-config.c +10 -0
@@ -653,6 +653,15 @@ QemuOptsList qemu_boot_opts = { }, }; +QemuOptsList qemu_object_opts = { + .name ="object" , + .implied_opt_name ="qom-type" , + .head =QTAILQ_HEAD_INITIALIZER (qemu_object_opts.head), + .desc = { + { } + }, +}; +static QemuOptsList *vm_config_groups[32 ] = { &qemu_drive_opts, &qemu_chardev_opts,
@@ -669,6 +678,7 @@ static QemuOptsList *vm_config_groups[32] = { &qemu_boot_opts, &qemu_iscsi_opts, &qemu_sandbox_opts, + &qemu_object_opts, NULL, };
qemu-options.hx +8 -0
@@ -2852,6 +2852,14 @@ STEXI Enable FIPS 140-2 compliance mode. ETEXI +DEF("object", HAS_ARG, QEMU_OPTION_object, + "-object TYPENAME[,PROP1=VALUE1,...]\n" + " create an new object of type TYPENAME setting properties\n" + " in the order they are specified. Note that the 'id'\n" + " property must be set. These objects are placed in the\n" + " '/objects' path.\n", + QEMU_ARCH_ALL) + HXCOMM This is the last statement. Insert new options before this line! STEXI @end table
vl.c +54 -0
78 lines not on this page · raw message
Signature · 1 line
1.7.7.6
PATCH 4/8 vl: add -late-object to create QOM objects after machine init
In reply to Amit ShahFrom: Anthony Liguori <[email protected]>
In order to create qdev objects via -late-object, we almost always have to specify the parent_bus which is usually created during machine init. Until we properly support two stage init, introduce a -late-object option that allows for creation of objects post-machine init.
--- qemu-config.c | 10 ++++++++++ qemu-options.hx | 12 ++++++++++++ vl.c | 14 +++++++++++--- 3 files changed, 33 insertions(+), 3 deletions(-)
qemu-config.c +10 -0
@@ -662,6 +662,15 @@ QemuOptsList qemu_object_opts = { }, }; +QemuOptsList qemu_late_object_opts = { + .name ="late-object" , + .implied_opt_name ="qom-type" , + .head =QTAILQ_HEAD_INITIALIZER (qemu_late_object_opts.head), + .desc = { + { } + }, +}; +static QemuOptsList *vm_config_groups[32 ] = { &qemu_drive_opts, &qemu_chardev_opts,
@@ -679,6 +688,7 @@ static QemuOptsList *vm_config_groups[32] = { &qemu_iscsi_opts, &qemu_sandbox_opts, &qemu_object_opts, + &qemu_late_object_opts, NULL, };
qemu-options.hx +12 -0
@@ -2860,6 +2860,18 @@ DEF("object", HAS_ARG, QEMU_OPTION_object, " '/objects' path.\n", QEMU_ARCH_ALL) +DEF("late-object", HAS_ARG, QEMU_OPTION_late_object, + "-late-object TYPENAME[,PROP1=VALUE1,...]\n" + " create an new object of type TYPENAME setting properties\n" + " in the order they are specified. Note that the 'id'\n" + " property must be set. These objects are placed in the\n" + " '/objects' path.\n" + "\n" + " Late objects are made after machine\n" + " initialization so they can refer to objects created by\n" + " the machine init function.\n", + QEMU_ARCH_ALL) + HXCOMM This is the last statement. Insert new options before this line! STEXI @end table
vl.c +11 -3
@@ -2395,13 +2395,14 @@ static int object_create(QemuOpts *opts, void *opaque) } obj =object_new (type); -if (qemu_opt_foreach (opts, object_set_property, obj,1 ) <0 ) { -return -1 ; - }object_property_add_child (container_get (object_get_root (),"/objects" ), id, obj,NULL ); +if (qemu_opt_foreach (opts, object_set_property, obj,1 ) <0 ) { +return -1 ; + } +return 0 ; }
@@ -3360,6 +3361,9 @@ int main(int argc, char **argv, char **envp)case QEMU_OPTION_object: opts =qemu_opts_parse (qemu_find_opts ("object" ), optarg,1 );break ; +case QEMU_OPTION_late_object: + opts =qemu_opts_parse (qemu_find_opts ("late-object" ), optarg,1 ); +break ;default :os_parse_cmd_args (popt->index, optarg); }
@@ -3706,6 +3710,10 @@ int main(int argc, char **argv, char **envp) current_machine = machine; +if (qemu_opts_foreach (qemu_find_opts ("late-object" ), object_create,NULL ,0 ) !=0 ) { +exit (1 ); + } +/* init USB devices */ if (usb_enabled) {if (foreach_device_config (DEV_USB , usb_parse) <0 )
Signature · 1 line
1.7.7.6
PATCH 5/8 rng: add RndBackend abstract object class
In reply to Amit ShahFrom: Anthony Liguori <[email protected]>
This is the backend used by devices that need to request entropy.
--- Makefile.objs | 2 + backends/Makefile.objs | 1 + backends/rng.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++ include/qemu/rng.h | 93 ++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 189 insertions(+), 0 deletions(-) create mode 100644 backends/Makefile.objs create mode 100644 backends/rng.c create mode 100644 include/qemu/rng.h
Makefile.objs +2 -0
@@ -100,6 +100,8 @@ common-obj-y += vl.o common-obj-$(CONFIG_SLIRP) += slirp/ +common-obj-y += backends/ + ###################################################################### # libseccomp ifeq ($(CONFIG_SECCOMP),y)
backends/Makefile.objs new file +1 -0
@@ -0,0 +1 @@ +common-obj-y += rng.o
backends/rng.c new file +93 -0
93 lines not on this page · raw message
include/qemu/rng.h new file +93 -0
93 lines not on this page · raw message
Signature · 1 line
1.7.7.6
PATCH 6/8 rng-urandom: add an RNG backend that uses /dev/urandom
In reply to Amit ShahFrom: Anthony Liguori <[email protected]>
The filename can be overridden but it expects a non-blocking source of entropy. A typical invocation would be:
qemu -object rng-urandom,id=rng0 -device virtio-rng-pci,rng=rng0
--- backends/Makefile.objs | 2 +- backends/rng-urandom.c | 144 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 145 insertions(+), 1 deletions(-) create mode 100644 backends/rng-urandom.c
backends/Makefile.objs +1 -1
@@ -1 +1 @@ -common-obj-y += rng.o +common-obj-y += rng.o rng-urandom.o
backends/rng-urandom.c new file +144 -0
144 lines not on this page · raw message
Signature · 1 line
1.7.7.6
PATCH 7/8 rng-egd: introduce EGD compliant RNG backend
In reply to Amit ShahFrom: Anthony Liguori <[email protected]>
This backend talks EGD to a CharDriverState. A typical way to invoke this would be:
qemu -chardev socket,host=localhost,port=1024,id=chr0 \
-object rng-egd,chardev=chr0,id=egd0 \
-device virtio-rng-pci,rng=egd0--- backends/Makefile.objs | 2 +- backends/rng-egd.c | 215 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 216 insertions(+), 1 deletions(-) create mode 100644 backends/rng-egd.c
backends/Makefile.objs +1 -1
@@ -1 +1 @@ -common-obj-y += rng.o rng-urandom.o +common-obj-y += rng.o rng-urandom.o rng-egd.o
backends/rng-egd.c new file +215 -0
215 lines not on this page · raw message
Signature · 1 line
1.7.7.6
PATCH 8/8 virtio-rng: hardware random number generator device
In reply to Amit ShahThe Linux kernel already has a virtio-rng driver, this is the device implementation.
When the guest asks for entropy from the virtio hwrng, it puts a buffer in the vq. We then put entropy into that buffer, and push it back to the guest.
--- hw/Makefile.objs | 1 + hw/pci.h | 1 + hw/s390-virtio-bus.c | 37 ++++++++++++ hw/s390-virtio-bus.h | 2 + hw/virtio-pci.c | 60 ++++++++++++++++++++ hw/virtio-pci.h | 2 + hw/virtio-rng.c | 149 ++++++++++++++++++++++++++++++++++++++++++++++++++ hw/virtio-rng.h | 24 ++++++++ hw/virtio.h | 3 + 9 files changed, 279 insertions(+), 0 deletions(-) create mode 100644 hw/virtio-rng.c create mode 100644 hw/virtio-rng.h
hw/Makefile.objs +1 -0
@@ -1,6 +1,7 @@ common-obj-y = usb/ ide/ common-obj-y += loader.o common-obj-$(CONFIG_VIRTIO) += virtio-console.o +common-obj-$(CONFIG_VIRTIO) += virtio-rng.o common-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o common-obj-y += fw_cfg.o common-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o
hw/pci.h +1 -0
@@ -76,6 +76,7 @@#define PCI_DEVICE_ID_VIRTIO_BALLOON 0x1002#define PCI_DEVICE_ID_VIRTIO_CONSOLE 0x1003#define PCI_DEVICE_ID_VIRTIO_SCSI 0x1004 +#define PCI_DEVICE_ID_VIRTIO_RNG 0x1005#define FMT_PCIBUS PRIx64
hw/s390-virtio-bus.c +37 -0
@@ -26,6 +26,7 @@#include "loader.h" #include "elf.h" #include "hw/virtio.h" +#include "hw/virtio-rng.h" #include "hw/virtio-serial.h" #include "hw/virtio-net.h" #include "hw/sysbus.h"
@@ -206,6 +207,18 @@ static int s390_virtio_scsi_init(VirtIOS390Device *dev)return s390_virtio_device_init (dev, vdev); } +static int s390_virtio_rng_init (VirtIOS390Device *dev) +{ +VirtIODevice *vdev; + + vdev =virtio_rng_init ((DeviceState *)dev, &dev->rng); +if (!vdev) { +return -1 ; + } + +return s390_virtio_device_init (dev, vdev); +} +static uint64_t s390_virtio_device_vq_token (VirtIOS390Device *dev,int vq) {ram_addr_t token_off;
@@ -448,6 +461,29 @@ static TypeInfo s390_virtio_serial = { .class_init = s390_virtio_serial_class_init, }; +static void s390_virtio_rng_initfn (Object *obj) +{ +VirtIOS390Device *dev =VIRTIO_S390_DEVICE (obj); + +object_property_add_link (obj,"rng" ,TYPE_RNG_BACKEND , + (Object **)&dev->rng.rng,NULL ); +} + +static void s390_virtio_rng_class_init (ObjectClass *klass,void *data) +{ +VirtIOS390DeviceClass *k =VIRTIO_S390_DEVICE_CLASS (klass); + + k->init = s390_virtio_rng_init; +} + +static TypeInfo s390_virtio_rng = { + .name ="virtio-rng-s390" , + .parent =TYPE_VIRTIO_S390_DEVICE , + .instance_size =sizeof (VirtIOS390Device), + .instance_init = s390_virtio_rng_initfn, + .class_init = s390_virtio_rng_class_init, +}; +static int s390_virtio_busdev_init (DeviceState *dev) {VirtIOS390Device *_dev = (VirtIOS390Device *)dev;
@@ -528,6 +564,7 @@ static void s390_virtio_register_types(void)type_register_static (&s390_virtio_blk);type_register_static (&s390_virtio_net);type_register_static (&s390_virtio_scsi); +type_register_static (&s390_virtio_rng);type_register_static (&s390_virtio_bridge_info); }
hw/s390-virtio-bus.h +2 -0
@@ -19,6 +19,7 @@#include "virtio-blk.h" #include "virtio-net.h" +#include "virtio-rng.h" #include "virtio-serial.h" #include "virtio-scsi.h"
@@ -75,6 +76,7 @@ struct VirtIOS390Device {virtio_serial_conf serial;virtio_net_conf net;VirtIOSCSIConf scsi; +VirtIORNGConf rng; }; typedef struct VirtIOS390Bus {
hw/virtio-pci.c +60 -0
78 lines not on this page · raw message
hw/virtio-pci.h +2 -0
@@ -17,6 +17,7 @@#include "virtio-blk.h" #include "virtio-net.h" +#include "virtio-rng.h" #include "virtio-serial.h" #include "virtio-scsi.h"
@@ -46,6 +47,7 @@ typedef struct {virtio_serial_conf serial;virtio_net_conf net;VirtIOSCSIConf scsi; +VirtIORNGConf rng;bool ioeventfd_disabled;bool ioeventfd_started;VirtIOIRQFD *vector_irqfd;
hw/virtio-rng.c new file +149 -0
149 lines not on this page · raw message
hw/virtio-rng.h new file +24 -0
@@ -0,0 +1,24 @@ +/* +* Virtio RNG Support +* +* Copyright Red Hat, Inc. 2012 +* Copyright Amit Shah <[email protected]> +* +* This work is licensed under the terms of the GNU GPL, version 2 or +* (at your option) any later version. See the COPYING file in the +* top-level directory. +*/ + +#ifndef _QEMU_VIRTIO_RNG_H +#define _QEMU_VIRTIO_RNG_H + +#include "qemu/rng.h" + +/* The Virtio ID for the virtio rng device */ +#define VIRTIO_ID_RNG 4 + +struct VirtIORNGConf { +RngBackend *rng; +}; + +#endif
hw/virtio.h +3 -0
@@ -203,6 +203,8 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, virtio_serial_conf *serial);VirtIODevice *virtio_balloon_init (DeviceState *dev);typedef struct VirtIOSCSIConf VirtIOSCSIConf ;VirtIODevice *virtio_scsi_init (DeviceState *dev,VirtIOSCSIConf *conf); +typedef struct VirtIORNGConf VirtIORNGConf ; +VirtIODevice *virtio_rng_init (DeviceState *dev,VirtIORNGConf *conf);#ifdef CONFIG_LINUX VirtIODevice *virtio_9p_init (DeviceState *dev,V9fsConf *conf);#endif
@@ -213,6 +215,7 @@ void virtio_blk_exit(VirtIODevice *vdev);void virtio_serial_exit (VirtIODevice *vdev);void virtio_balloon_exit (VirtIODevice *vdev);void virtio_scsi_exit (VirtIODevice *vdev); +void virtio_rng_exit (VirtIODevice *vdev);#define DEFINE_VIRTIO_COMMON_FEATURES (_state, _field) \ DEFINE_PROP_BIT("indirect_desc", _state, _field, \
Signature · 1 line
1.7.7.6
Il 26/10/2012 13:01, Amit Shah ha scritto:
Quoted 12 lines
Amit Shah (1):
virtio-rng: hardware random number generator deviceAnthony Liguori (7):
object: addobject_property_add_bool(v2)
qdev: add realized property and make adding child bus implied by
realize
vl: add -object option to create QOM objects from the command line
vl: add -late-object to create QOM objects after machine init
rng: add RndBackend abstract object class
rng-urandom: add an RNG backend that uses/dev/urandom
rng-egd: introduce EGD compliant RNG backend
Honestly I think this is overengineered.
I would instead have the following:
- a chardev that can read from a file (e.g. -chardev file,path=/dev/urandom,read=on,id=urandom)
- a device that accepts a chardev and understands both egd and raw (e.g. -device virtio-rng-pci,chardev=urandom,egd=off or -device virtio-rng-pci,chardev=egdsock,egd=on).
- optionally, a chardev that can produce an endless stream of data via rdrand.
And that's it.
Also, even if RngBackend goes in, there is no need for -late-object right now, so I would not include it in this series.
Paolo
Quoted 14 lines · Paolo Bonzini
Il 26/10/2012 13:01, Amit Shah ha scritto:
Quoted 12 lines
Amit Shah (1):
virtio-rng: hardware random number generator deviceAnthony Liguori (7):
object: addobject_property_add_bool(v2)
qdev: add realized property and make adding child bus implied by
realize
vl: add -object option to create QOM objects from the command line
vl: add -late-object to create QOM objects after machine init
rng: add RndBackend abstract object class
rng-urandom: add an RNG backend that uses/dev/urandom
rng-egd: introduce EGD compliant RNG backend
Quoted 6 lines
Honestly I think this is overengineered.
I would instead have the following:
- a chardev that can read from a file (e.g. -chardev file,path=/dev/urandom,read=on,id=urandom)
Then your multiplexing lots of logic into the chardev layer.
Three of these patches can be dropped. See the series I sent out.
Regards,
Anthony Liguori
Quoted 15 lines
- a device that accepts a chardev and understands both egd and raw (e.g.
-device virtio-rng-pci,chardev=urandom,egd=off or -device virtio-rng-pci,chardev=egdsock,egd=on).
- optionally, a chardev that can produce an endless stream of data via rdrand.
And that's it.
Also, even if RngBackend goes in, there is no need for -late-object right now, so I would not include it in this series.
Paolo
Il 26/10/2012 17:14, Anthony Liguori ha scritto:
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
I would instead have the following:
- a chardev that can read from a file (e.g. -chardev file,path=/dev/urandom,read=on,id=urandom)
Then your multiplexing lots of logic into the chardev layer.
Then call it -chardev filein,path=/dev/urandom,id=urandom. :)
Quoted 1 line
Three of these patches can be dropped. See the series I sent out.
Same comments apply there...
Paolo
Quoted 8 lines · Paolo Bonzini
Il 26/10/2012 17:14, Anthony Liguori ha scritto:
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
I would instead have the following:
- a chardev that can read from a file (e.g. -chardev file,path=/dev/urandom,read=on,id=urandom)
Then your multiplexing lots of logic into the chardev layer.
Then call it -chardev filein,path=/dev/urandom,id=urandom. :)
Let's move this to my thread please...
Regards,
Anthony Liguori
Quoted 6 lines
Quoted 2 lines
Three of these patches can be dropped. See the series I sent out.
Same comments apply there...
Paolo