Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On Tue, Jun 05, 2012 at 03:46:31PM +0530, Amit Shah wrote:
On (Tue) 05 Jun 2012 [17:54:30], Anthony Liguori wrote:
On 06/05/2012 05:41 PM, Amit Shah wrote:
On (Mon) 04 Jun 2012 [19:04:41], Anthony Liguori wrote:
On 05/26/2012 04:20 AM, Amit Shah wrote:
On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote:
On 05/25/2012 02:32 PM, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo/dev/urandom
A QMP event is sent for interested apps to monitor activity and send
the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
I don't understand the point of this event. Can't a management app
just create a socket and then it can see all the requests the guest
makes?
How? With the chardev, it can only keep feeding data, and that data
will be consumed when chr_can_read() returns 0. And even then the
mgmt app has no idea how much data was asked for, and how much was
consumed.
Okay, then the right approach is to use a message protocol where
QEMU asks for a certain amount of data and then the daemon sends it
back.
Why is a message protocol necessary? And a daemon isn't necessary,
too.
I think this is pretty much why the egd protocol exists, no? Why
not just implement egd protocol support?
Perhaps I'm not getting what you're saying.
What we have here, via the event, is to tell the mgmt app that the
guest has need for entropy.
*out-of-band*
Why not just make that all in-band?
I understand you're trying to accomodate a use-case of feeding
/dev/random to QEMU. I don't think this is a necessary use-case
though because I don't think it's correct. You need to use an
entropy daemon of some sort to make sure entropy is being
distributed in a fair fashion.
In my view, qemu doesn't operate at a system-level where it can see
how system entropy is being used.
libvirt does operate at that level.
For casual development, I don't want to have egd on my system to feed
in entropy to the guest, and I don't need to know how to configure
egd and then provide its output to qemu.
libvirt can do that for me. But for development, I'd just want to be
able to do something like
qemu -chardev socket,path=/tmp/foo,id=foo,server,nowait \
-device virtio-rng,chardev=foo
and then just feed in some data to /tmp/foo.
I tend to agree, while the EGD wire protocol may be useful if you
are wanting to connect QEMU to EGD, for apps that are just directly
mnanaging QEMU it imposes a unnecessary burden on apps, to learn
a new protocol in addition to their existing knowledge of QMP.
In addition, I don't think implementing the EGD protocol is mutually
exclusive with raw QEMU chardevs. eg enablement of an EGD protocol on
the chardev could reasonably be done as an optional feature ontop of
the raw chardev, in the same way that chardevs can be made to optionally
run the telnet line discipline.
I'd like to see us have the raw chardev impl + QMP event as a first
step, and then add EGD protocol on top of that (if desired) as a
second step.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On (Mon) 04 Jun 2012 [19:04:41], Anthony Liguori wrote:
On 05/26/2012 04:20 AM, Amit Shah wrote:
On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote:
On 05/25/2012 02:32 PM, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
I don't understand the point of this event. Can't a management app
just create a socket and then it can see all the requests the guest
makes?
How? With the chardev, it can only keep feeding data, and that data
will be consumed when chr_can_read() returns 0. And even then the
mgmt app has no idea how much data was asked for, and how much was
consumed.
Okay, then the right approach is to use a message protocol where
QEMU asks for a certain amount of data and then the daemon sends it
back.
Why is a message protocol necessary? And a daemon isn't necessary,
too.
I think this is pretty much why the egd protocol exists, no? Why
not just implement egd protocol support?
Perhaps I'm not getting what you're saying.
What we have here, via the event, is to tell the mgmt app that the
guest has need for entropy. The guest also tells us exactly how many
bytes it needs. We're just passing on that info to the mgmt app, if
it needs it.
In any case, any data pushed down the chardev will be consumed by the
device, and sent to the guest when the guest puts a buf in the vq.
Once we introduce a protocol of any form (even raw), we have to
support it forever so let's not do it carelessly.
There's no need for a protocol at all here. Can you skim through the
code and point out where you think we're disagreeing?
Amit
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On 06/05/2012 05:41 PM, Amit Shah wrote:
On (Mon) 04 Jun 2012 [19:04:41], Anthony Liguori wrote:
On 05/26/2012 04:20 AM, Amit Shah wrote:
On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote:
On 05/25/2012 02:32 PM, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo/dev/urandom
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
I don't understand the point of this event. Can't a management app
just create a socket and then it can see all the requests the guest
makes?
How? With the chardev, it can only keep feeding data, and that data
will be consumed when chr_can_read() returns 0. And even then the
mgmt app has no idea how much data was asked for, and how much was
consumed.
Okay, then the right approach is to use a message protocol where
QEMU asks for a certain amount of data and then the daemon sends it
back.
Why is a message protocol necessary? And a daemon isn't necessary,
too.
I think this is pretty much why the egd protocol exists, no? Why
not just implement egd protocol support?
Perhaps I'm not getting what you're saying.
What we have here, via the event, is to tell the mgmt app that the
guest has need for entropy.
*out-of-band*
Why not just make that all in-band?
I understand you're trying to accomodate a use-case of feeding /dev/random to
QEMU. I don't think this is a necessary use-case though because I don't think
it's correct. You need to use an entropy daemon of some sort to make sure
entropy is being distributed in a fair fashion.
The guest also tells us exactly how many
bytes it needs. We're just passing on that info to the mgmt app, if
it needs it.
In any case, any data pushed down the chardev will be consumed by the
device, and sent to the guest when the guest puts a buf in the vq.
Once we introduce a protocol of any form (even raw), we have to
support it forever so let's not do it carelessly.
There's no need for a protocol at all here.
The event *is* a protocol. That's the point.
Here's what you're making a management app do:
1) Open a socket
2) Feed socket fd to QEMU
3) Listen for event on QMP for entropy request
4) Read entropy based on (3) from /dev/random
5) Send entropy to socket to QEMU
This is pretty silly when you can just do:
1) Open a socket
2) Listen for entropy request
3) Read entry based on (2) from /dev/random
4) Respond to (2) with (3)
And there's already a tool and protocol for exactly the above--egd.
There's simply no good reason to involve QMP here.
Regards,
Anthony Liguori
Can you skim through the
code and point out where you think we're disagreeing?
Amit
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On (Tue) 05 Jun 2012 [17:54:30], Anthony Liguori wrote:
On 06/05/2012 05:41 PM, Amit Shah wrote:
On (Mon) 04 Jun 2012 [19:04:41], Anthony Liguori wrote:
On 05/26/2012 04:20 AM, Amit Shah wrote:
On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote:
On 05/25/2012 02:32 PM, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo/dev/urandom
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
I don't understand the point of this event. Can't a management app
just create a socket and then it can see all the requests the guest
makes?
How? With the chardev, it can only keep feeding data, and that data
will be consumed when chr_can_read() returns 0. And even then the
mgmt app has no idea how much data was asked for, and how much was
consumed.
Okay, then the right approach is to use a message protocol where
QEMU asks for a certain amount of data and then the daemon sends it
back.
Why is a message protocol necessary? And a daemon isn't necessary,
too.
I think this is pretty much why the egd protocol exists, no? Why
not just implement egd protocol support?
Perhaps I'm not getting what you're saying.
What we have here, via the event, is to tell the mgmt app that the
guest has need for entropy.
*out-of-band*
Why not just make that all in-band?
I understand you're trying to accomodate a use-case of feeding
/dev/random to QEMU. I don't think this is a necessary use-case
though because I don't think it's correct. You need to use an
entropy daemon of some sort to make sure entropy is being
distributed in a fair fashion.
In my view, qemu doesn't operate at a system-level where it can see
how system entropy is being used.
libvirt does operate at that level.
For casual development, I don't want to have egd on my system to feed
in entropy to the guest, and I don't need to know how to configure
egd and then provide its output to qemu.
libvirt can do that for me. But for development, I'd just want to be
able to do something like
qemu -chardev socket,path=/tmp/foo,id=foo,server,nowait \
-device virtio-rng,chardev=foo
and then just feed in some data to /tmp/foo.
The guest also tells us exactly how many
bytes it needs. We're just passing on that info to the mgmt app, if
it needs it.
In any case, any data pushed down the chardev will be consumed by the
device, and sent to the guest when the guest puts a buf in the vq.
Once we introduce a protocol of any form (even raw), we have to
support it forever so let's not do it carelessly.
There's no need for a protocol at all here.
The event *is* a protocol. That's the point.
But there is no requirement to use the event. From the cmdline above,
I can just do something like
nc -U /tmp/foo /dev/urandom
and forget about the event. The event is just a way to tell
interested apps what the guest did. Nothing more.
Here's what you're making a management app do:
1) Open a socket
2) Feed socket fd to QEMU
3) Listen for event on QMP for entropy request
This step isn't necessary.
4) Read entropy based on (3) from /dev/random
5) Send entropy to socket to QEMU
This is pretty silly when you can just do:
1) Open a socket
2) Listen for entropy request
3) Read entry based on (2) from /dev/random
4) Respond to (2) with (3)
Quoting danpb's mail from this thread:
IIUC, there are three ways mgmt apps can use the RNG with the
chardev
- Wire it up to a source that just blindly provides all the
entropy QEMU desires (as you /dev/urandom example above)
- Feed in a fixed amount of entropy every minute, regardless
of how much QEMU desires
- Feed in entropy on demand, in response to the ENTROPY_NEEDED
event notification (possibly throttling)
These options sounds like they should cover all reasonable needs,
so gets my vote. Probably want to include the ENTROPY_NEEDED
event in my patch which adds rate limiting to guest initiated
events.
Amit
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On 05/26/2012 04:20 AM, Amit Shah wrote:
On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote:
On 05/25/2012 02:32 PM, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
I don't understand the point of this event. Can't a management app
just create a socket and then it can see all the requests the guest
makes?
How? With the chardev, it can only keep feeding data, and that data
will be consumed when chr_can_read() returns 0. And even then the
mgmt app has no idea how much data was asked for, and how much was
consumed.
Okay, then the right approach is to use a message protocol where QEMU asks for a
certain amount of data and then the daemon sends it back.
I think this is pretty much why the egd protocol exists, no? Why not just
implement egd protocol support?
Once we introduce a protocol of any form (even raw), we have to support it
forever so let's not do it carelessly.
Regards,
Anthony Liguori
Amit
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On Sat, May 26, 2012 at 01:02:49AM +0530, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
ACK to this ARGV design from a libvirt POV.
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
IIUC, there are three ways mgmt apps can use the RNG with the
chardev
- Wire it up to a source that just blindly provides all the
entropy QEMU desires (as you /dev/urandom example above)
- Feed in a fixed amount of entropy every minute, regardless
of how much QEMU desires
- Feed in entropy on demand, in response to the ENTROPY_NEEDED
event notification (possibly throttling)
These options sounds like they should cover all reasonable needs,
so gets my vote. Probably want to include the ENTROPY_NEEDED
event in my patch which adds rate limiting to guest initiated
events.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On (Mon) 28 May 2012 [09:33:57], Daniel P. Berrange wrote:
On Sat, May 26, 2012 at 01:02:49AM +0530, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
ACK to this ARGV design from a libvirt POV.
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
IIUC, there are three ways mgmt apps can use the RNG with the
chardev
- Wire it up to a source that just blindly provides all the
entropy QEMU desires (as you /dev/urandom example above)
- Feed in a fixed amount of entropy every minute, regardless
of how much QEMU desires
This option currently won't do anything -- i.e. till the guest sends
across a buffer to be filled in, nothing will go to the guest, and the
data will just be buffered in the chardev layer till such a buffer
comes along. It can be debatable on feeding entropy by pushing every
particular timeout, or just providing the freshest on-demand.
Advantage could be we have more random bits, disadvantage is this
could be throttled as the host went out of enough entropy.
- Feed in entropy on demand, in response to the ENTROPY_NEEDED
event notification (possibly throttling)
These options sounds like they should cover all reasonable needs,
so gets my vote.
Great!
Probably want to include the ENTROPY_NEEDED
event in my patch which adds rate limiting to guest initiated
events.
Yes, just depends in which order the patches go in.
Thanks,
Amit
[Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
Signed-off-by: Amit Shah amit.s...@redhat.com
---
Makefile.objs|1 +
hw/pci.h |1 +
hw/s390-virtio-bus.c | 35 +
hw/s390-virtio-bus.h |2 +
hw/virtio-pci.c | 51 +
hw/virtio-pci.h |2 +
hw/virtio-rng.c | 199 ++
hw/virtio-rng.h | 24 ++
hw/virtio.h |3 +
monitor.c|3 +
monitor.h|1 +
11 files changed, 322 insertions(+), 0 deletions(-)
create mode 100644 hw/virtio-rng.c
create mode 100644 hw/virtio-rng.h
diff --git a/Makefile.objs b/Makefile.objs
index 70c5c79..5850762 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -210,6 +210,7 @@ user-obj-y += $(qom-obj-twice-y)
hw-obj-y =
hw-obj-y += vl.o loader.o
hw-obj-$(CONFIG_VIRTIO) += virtio-console.o
+hw-obj-$(CONFIG_VIRTIO) += virtio-rng.o
hw-obj-y += usb/libhw.o
hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
hw-obj-y += fw_cfg.o
diff --git a/hw/pci.h b/hw/pci.h
index 8d0aa49..0a22f91 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -76,6 +76,7 @@
#define PCI_DEVICE_ID_VIRTIO_BALLOON 0x1002
#define PCI_DEVICE_ID_VIRTIO_CONSOLE 0x1003
#define PCI_DEVICE_ID_VIRTIO_SCSI0x1004
+#define PCI_DEVICE_ID_VIRTIO_RNG 0x1005
#define FMT_PCIBUS PRIx64
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index 1d38a8f..e75711e 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -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
@@ -204,6 +205,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;
@@ -445,6 +458,27 @@ static TypeInfo s390_virtio_serial = {
.class_init= s390_virtio_serial_class_init,
};
+static Property s390_virtio_rng_properties[] = {
+DEFINE_PROP_CHR(chardev, VirtIOS390Device, rng.chr),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void s390_virtio_rng_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtIOS390DeviceClass *k = VIRTIO_S390_DEVICE_CLASS(klass);
+
+k-init = s390_virtio_rng_init;
+dc-props = s390_virtio_rng_properties;
+}
+
+static TypeInfo s390_virtio_rng = {
+.name = virtio-rng-s390,
+.parent= TYPE_VIRTIO_S390_DEVICE,
+.instance_size = sizeof(VirtIOS390Device),
+.class_init= s390_virtio_rng_class_init,
+};
+
static int s390_virtio_busdev_init(DeviceState *dev)
{
VirtIOS390Device *_dev = (VirtIOS390Device *)dev;
@@ -524,6 +558,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);
}
diff --git a/hw/s390-virtio-bus.h b/hw/s390-virtio-bus.h
index 4b99d02..5fc53b3 100644
--- a/hw/s390-virtio-bus.h
+++ b/hw/s390-virtio-bus.h
@@ -19,6 +19,7 @@
#include virtio-blk.h
#include virtio-net.h
+#include virtio-rng.h
#include virtio-serial.h
#include virtio-scsi.h
@@ -71,6 +72,7 @@ struct VirtIOS390Device {
virtio_serial_conf serial;
virtio_net_conf net;
VirtIOSCSIConf scsi;
+VirtIORNGConf rng;
};
typedef struct VirtIOS390Bus {
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 79b86f1..bd5851e 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -810,6 +810,28 @@ static int virtio_balloon_exit_pci(PCIDevice *pci_dev)
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On 05/25/2012 02:32 PM, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
I don't understand the point of this event. Can't a management app just create
a socket and then it can see all the requests the guest makes?
Regards,
Anthony Liguori
Signed-off-by: Amit Shahamit.s...@redhat.com
---
Makefile.objs|1 +
hw/pci.h |1 +
hw/s390-virtio-bus.c | 35 +
hw/s390-virtio-bus.h |2 +
hw/virtio-pci.c | 51 +
hw/virtio-pci.h |2 +
hw/virtio-rng.c | 199 ++
hw/virtio-rng.h | 24 ++
hw/virtio.h |3 +
monitor.c|3 +
monitor.h|1 +
11 files changed, 322 insertions(+), 0 deletions(-)
create mode 100644 hw/virtio-rng.c
create mode 100644 hw/virtio-rng.h
diff --git a/Makefile.objs b/Makefile.objs
index 70c5c79..5850762 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -210,6 +210,7 @@ user-obj-y += $(qom-obj-twice-y)
hw-obj-y =
hw-obj-y += vl.o loader.o
hw-obj-$(CONFIG_VIRTIO) += virtio-console.o
+hw-obj-$(CONFIG_VIRTIO) += virtio-rng.o
hw-obj-y += usb/libhw.o
hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
hw-obj-y += fw_cfg.o
diff --git a/hw/pci.h b/hw/pci.h
index 8d0aa49..0a22f91 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -76,6 +76,7 @@
#define PCI_DEVICE_ID_VIRTIO_BALLOON 0x1002
#define PCI_DEVICE_ID_VIRTIO_CONSOLE 0x1003
#define PCI_DEVICE_ID_VIRTIO_SCSI0x1004
+#define PCI_DEVICE_ID_VIRTIO_RNG 0x1005
#define FMT_PCIBUS PRIx64
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index 1d38a8f..e75711e 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -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
@@ -204,6 +205,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;
@@ -445,6 +458,27 @@ static TypeInfo s390_virtio_serial = {
.class_init= s390_virtio_serial_class_init,
};
+static Property s390_virtio_rng_properties[] = {
+DEFINE_PROP_CHR(chardev, VirtIOS390Device, rng.chr),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void s390_virtio_rng_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtIOS390DeviceClass *k = VIRTIO_S390_DEVICE_CLASS(klass);
+
+k-init = s390_virtio_rng_init;
+dc-props = s390_virtio_rng_properties;
+}
+
+static TypeInfo s390_virtio_rng = {
+.name = virtio-rng-s390,
+.parent= TYPE_VIRTIO_S390_DEVICE,
+.instance_size = sizeof(VirtIOS390Device),
+.class_init= s390_virtio_rng_class_init,
+};
+
static int s390_virtio_busdev_init(DeviceState *dev)
{
VirtIOS390Device *_dev = (VirtIOS390Device *)dev;
@@ -524,6 +558,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);
}
diff --git a/hw/s390-virtio-bus.h b/hw/s390-virtio-bus.h
index 4b99d02..5fc53b3 100644
--- a/hw/s390-virtio-bus.h
+++ b/hw/s390-virtio-bus.h
@@ -19,6 +19,7 @@
#include virtio-blk.h
#include virtio-net.h
+#include virtio-rng.h
#include virtio-serial.h
#include virtio-scsi.h
@@ -71,6 +72,7 @@ struct VirtIOS390Device {
virtio_serial_conf serial;
virtio_net_conf net;
Re: [Qemu-devel] [PATCH v2 1/1] virtio-rng: hardware random number generator device
On (Fri) 25 May 2012 [15:00:53], Anthony Liguori wrote:
On 05/25/2012 02:32 PM, Amit Shah wrote:
The 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.
The chardev connected to this device is fed the data to be sent to the
guest.
Invocation is simple:
$ qemu ... -device virtio-rng-pci,chardev=foo
In the guest, we see
$ cat /sys/devices/virtual/misc/hw_random/rng_available
virtio
$ cat /sys/devices/virtual/misc/hw_random/rng_current
virtio
# cat /dev/hwrng
Simply feeding /dev/urandom from the host to the chardev is sufficient:
$ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
-device virtio-rng,chardev=foo
$ nc -U /tmp/foo /dev/urandom
A QMP event is sent for interested apps to monitor activity and send the
appropriate number of bytes that get asked by the guest:
{timestamp: {seconds: 1337966878, microseconds: 517009}, \
event: ENTROPY_NEEDED, data: {bytes: 64}}
I don't understand the point of this event. Can't a management app
just create a socket and then it can see all the requests the guest
makes?
How? With the chardev, it can only keep feeding data, and that data
will be consumed when chr_can_read() returns 0. And even then the
mgmt app has no idea how much data was asked for, and how much was
consumed.
Amit
