search for: rng_current

...changed, 1 insertion(+) > create mode 100644 90-virtio-rng.rules > > diff --git a/90-virtio-rng.rules b/90-virtio-rng.rules > new file mode 100644 > index 0000000..07f2f9c > --- /dev/null > +++ b/90-virtio-rng.rules > @@ -0,0 +1 @@ > +KERNEL=="hw_random", ATTR{rng_current}=="virtio*", RUN+="/sbin/rngd -r /dev/hwrng" > I'm not sure this is really right. rngd can receive input from a number of sources, and I suspect it would be better to rngd to be started much earlier and perhaps get sent a SIGHUP to reconfigure when a hw_random device a...

...changed, 1 insertion(+) > create mode 100644 90-virtio-rng.rules > > diff --git a/90-virtio-rng.rules b/90-virtio-rng.rules > new file mode 100644 > index 0000000..07f2f9c > --- /dev/null > +++ b/90-virtio-rng.rules > @@ -0,0 +1 @@ > +KERNEL=="hw_random", ATTR{rng_current}=="virtio*", RUN+="/sbin/rngd -r /dev/hwrng" > I'm not sure this is really right. rngd can receive input from a number of sources, and I suspect it would be better to rngd to be started much earlier and perhaps get sent a SIGHUP to reconfigure when a hw_random device a...

...e 100644 90-virtio-rng.rules > > > > diff --git a/90-virtio-rng.rules b/90-virtio-rng.rules > > new file mode 100644 > > index 0000000..07f2f9c > > --- /dev/null > > +++ b/90-virtio-rng.rules > > @@ -0,0 +1 @@ > > +KERNEL=="hw_random", ATTR{rng_current}=="virtio*", RUN+="/sbin/rngd -r /dev/hwrng" > > > > I'm not sure this is really right. rngd can receive input from a number > of sources, and I suspect it would be better to rngd to be started much > earlier and perhaps get sent a SIGHUP to reconfigure...

...party, but: On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong <akong at redhat.com> wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > There's currently a big lock around everything, and it means that we > can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) > while the rng is reading. This is a real problem when the rng is slow, > or blocked (eg. virtio_rng with qemu's default /dev/random backend) > > This doesn't help (it leaves the current lock untouched), just adds a > lock to protect the read function and the static buffer...

...party, but: On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong <akong at redhat.com> wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > There's currently a big lock around everything, and it means that we > can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) > while the rng is reading. This is a real problem when the rng is slow, > or blocked (eg. virtio_rng with qemu's default /dev/random backend) > > This doesn't help (it leaves the current lock untouched), just adds a > lock to protect the read function and the static buffer...

...d 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 -n virtio_rng.1 > /sys/class/misc/hw_random/rng_current ]# dd if=/dev/hwrng of=/dev/null Signed-off-by: Amos Kong <akong at redhat.com> --- drivers/char/hw_random/virtio-rng.c | 102 ++++++++++++++++++++++-------------- include/linux/hw_random.h | 2 +- 2...

...d 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 -n virtio_rng.1 > /sys/class/misc/hw_random/rng_current ]# dd if=/dev/hwrng of=/dev/null Signed-off-by: Amos Kong <akong at redhat.com> --- drivers/char/hw_random/virtio-rng.c | 102 ++++++++++++++++++++++-------------- include/linux/hw_random.h | 2 +- 2...

Hello, I didn't find a mailing list for rng-tools, so CC'ing the kernel lists and the last few committers. The first patch in this series adds a udev rule to start rngd for guests that have a virtio-rng device available. The second patch attempts to add autoconf magic to install the udev rule in the system dirs. However, installing as non-root will obviously fail. Prefixes are also

Hello, I didn't find a mailing list for rng-tools, so CC'ing the kernel lists and the last few committers. The first patch in this series adds a udev rule to start rngd for guests that have a virtio-rng device available. The second patch attempts to add autoconf magic to install the udev rule in the system dirs. However, installing as non-root will obviously fail. Prefixes are also

...50 AM, Amos Kong <akong at redhat.com> wrote: > > > From: Rusty Russell <rusty at rustcorp.com.au> > > > > > > There's currently a big lock around everything, and it means that we > > > can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) > > > while the rng is reading. This is a real problem when the rng is slow, > > > or blocked (eg. virtio_rng with qemu's default /dev/random backend) > > > > > > This doesn't help (it leaves the current lock untouched), just adds a > > > lock...

...50 AM, Amos Kong <akong at redhat.com> wrote: > > > From: Rusty Russell <rusty at rustcorp.com.au> > > > > > > There's currently a big lock around everything, and it means that we > > > can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) > > > while the rng is reading. This is a real problem when the rng is slow, > > > or blocked (eg. virtio_rng with qemu's default /dev/random backend) > > > > > > This doesn't help (it leaves the current lock untouched), just adds a > > > lock...

From: Rusty Russell <rusty at rustcorp.com.au> current_rng holds one reference, and we bump it every time we want to do a read from it. This means we only hold the rng_mutex to grab or drop a reference, so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't block on read of /dev/hwrng. Using a kref is overkill (we're always under the rng_mutex), but a standard pattern. This also solves the problem that the hwrng_fillfn thread was accessing current_rng without a lock, which could change (eg. to NULL) underneath it. v4: decrease last...

From: Rusty Russell <rusty at rustcorp.com.au> current_rng holds one reference, and we bump it every time we want to do a read from it. This means we only hold the rng_mutex to grab or drop a reference, so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't block on read of /dev/hwrng. Using a kref is overkill (we're always under the rng_mutex), but a standard pattern. This also solves the problem that the hwrng_fillfn thread was accessing current_rng without a lock, which could change (eg. to NULL) underneath it. v4: decrease last...

...ote: > From: Rusty Russell <rusty at rustcorp.com.au> > > current_rng holds one reference, and we bump it every time we want > to do a read from it. > > This means we only hold the rng_mutex to grab or drop a reference, > so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't > block on read of /dev/hwrng. > > Using a kref is overkill (we're always under the rng_mutex), but > a standard pattern. > > This also solves the problem that the hwrng_fillfn thread was > accessing current_rng without a lock, which could change (eg. to NULL)...

...ote: > From: Rusty Russell <rusty at rustcorp.com.au> > > current_rng holds one reference, and we bump it every time we want > to do a read from it. > > This means we only hold the rng_mutex to grab or drop a reference, > so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't > block on read of /dev/hwrng. > > Using a kref is overkill (we're always under the rng_mutex), but > a standard pattern. > > This also solves the problem that the hwrng_fillfn thread was > accessing current_rng without a lock, which could change (eg. to NULL)...

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My original was pain, Rusty posted a real fix. This patchset fixed two issue in v1, and tested by my 6+ cases. | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: |

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My original was pain, Rusty posted a real fix. This patchset fixed two issue in v1, and tested by my 6+ cases. | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: |

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test