similar to: [PATCH] virtio-rng: Remove false BUG for spurious callbacks

If virtio_rng is build as a module, random_data is an address in vmalloc space. As virtio expects guest real addresses, this can cause any kind of funny behaviour, so lets allocate random_data dynamically with kmalloc. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- drivers/char/hw_random/virtio-rng.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)

If virtio_rng is build as a module, random_data is an address in vmalloc space. As virtio expects guest real addresses, this can cause any kind of funny behaviour, so lets allocate random_data dynamically with kmalloc. Signed-off-by: Christian Borntraeger <borntraeger at de.ibm.com> --- drivers/char/hw_random/virtio-rng.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)

Rusty, I have seen an oops triggered by the following bug statement in virtio-rng: if (vq->vq_ops->add_buf(vq, &sg, 0, 1, &random_data) != 0) BUG(); The problem is that we never called get_buf for complete buffers. The fix is simple: We have to free the buffer on interrupt to avoid a virtqueue "overflow". Christian Signed-off-by: Christian Borntraeger

Rusty, I have seen an oops triggered by the following bug statement in virtio-rng: if (vq->vq_ops->add_buf(vq, &sg, 0, 1, &random_data) != 0) BUG(); The problem is that we never called get_buf for complete buffers. The fix is simple: We have to free the buffer on interrupt to avoid a virtqueue "overflow". Christian Signed-off-by: Christian Borntraeger

Rusty, This patch changes the virtio_rng to a callback without a return value. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> --- drivers/char/hw_random/virtio-rng.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Index: kvm/drivers/char/hw_random/virtio-rng.c =================================================================== ---

Rusty, This patch changes the virtio_rng to a callback without a return value. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> --- drivers/char/hw_random/virtio-rng.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Index: kvm/drivers/char/hw_random/virtio-rng.c =================================================================== ---

From 2334d90a3b9f8b9207163e9e0fad714e88a28771 Mon Sep 17 00:00:00 2001 From: Rusty Russell <rusty@rustcorp.com.au> Date: Wed, 7 Nov 2007 21:02:22 +1100 Subject: [PATCH] virtio: An entropy device, as suggested by hpa. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- Documentation/lguest/lguest.c | 53 +++++++++++++++ drivers/char/hw_random/Kconfig | 10 +++

From 2334d90a3b9f8b9207163e9e0fad714e88a28771 Mon Sep 17 00:00:00 2001 From: Rusty Russell <rusty@rustcorp.com.au> Date: Wed, 7 Nov 2007 21:02:22 +1100 Subject: [PATCH] virtio: An entropy device, as suggested by hpa. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- Documentation/lguest/lguest.c | 53 +++++++++++++++ drivers/char/hw_random/Kconfig | 10 +++

Current hwrng core supports to register multiple hwrng devices, and there is only one device really works in the same time. QEMU alsu supports to have multiple virtio-rng backends. This patch changes virtio-rng driver to support multiple virtio-rng devices. ]# cat /sys/class/misc/hw_random/rng_available virtio_rng.0 virtio_rng.1 ]# cat /sys/class/misc/hw_random/rng_current virtio_rng.0 ]# echo

Current hwrng core supports to register multiple hwrng devices, and there is only one device really works in the same time. QEMU alsu supports to have multiple virtio-rng backends. This patch changes virtio-rng driver to support multiple virtio-rng devices. ]# cat /sys/class/misc/hw_random/rng_available virtio_rng.0 virtio_rng.1 ]# cat /sys/class/misc/hw_random/rng_current virtio_rng.0 ]# echo

On Thu, Jan 19, 2023 at 07:43:47PM +0100, Babis Chalios wrote: > Implement the virtio-rng feature that allows a guest driver to request > from the device to perform certain operations in the event of an > "entropy leak", such as when taking a VM snapshot or restoring a VM from > a snapshot. The guest can request one of two operations: (i) fill a > buffer with random bytes,

This API change means that virtio_net can tell how much capacity remains for buffers. It's necessarily fuzzy, since VIRTIO_RING_F_INDIRECT_DESC means we can fit any number of descriptors in one, *if* we can kmalloc. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Dinesh Subhraveti <dineshs at us.ibm.com> --- drivers/block/virtio_blk.c | 2 +-

This API change means that virtio_net can tell how much capacity remains for buffers. It's necessarily fuzzy, since VIRTIO_RING_F_INDIRECT_DESC means we can fit any number of descriptors in one, *if* we can kmalloc. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Dinesh Subhraveti <dineshs at us.ibm.com> --- drivers/block/virtio_blk.c | 2 +-

The hwrng core asks for random data in the hwrng_register() call itself from commit d9e7972619. This doesn't play well with virtio -- the DRIVER_OK bit is only set by virtio core on a successful probe, and we're not yet out of our probe routine when this call is made. This causes the host to not acknowledge any requests we put in the virtqueue, and the insmod or kernel boot process just

This is a 3.16-only patch. The linux.git fix is 5c06273401f2eb7b290cadbae18ee00f8f65e893, which fixes this issue in a different way. Amos reported using multiple virtio-rng devices cause boot to freeze even after the recent fixes. We need the probe_done test per device rather than just once for the driver. Reported-by: Amos Kong <akong at redhat.com> Signed-off-by: Amit Shah

This is a 3.16-only patch. The linux.git fix is 5c06273401f2eb7b290cadbae18ee00f8f65e893, which fixes this issue in a different way. Amos reported using multiple virtio-rng devices cause boot to freeze even after the recent fixes. We need the probe_done test per device rather than just once for the driver. Reported-by: Amos Kong <akong at redhat.com> Signed-off-by: Amit Shah

On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes

On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes

On Sat, Jul 05, 2014 at 11:04:53AM +0530, Amit Shah wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes the host to not

On Sat, Jul 05, 2014 at 11:04:53AM +0530, Amit Shah wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes the host to not