similar to: pass-through hwrng

On Thu, Sep 18, 2014 at 08:37:44PM +0800, Amos Kong wrote: > 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

On Thu, Sep 18, 2014 at 08:37:44PM +0800, Amos Kong wrote: > 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

Commit d9e7972619334 "hwrng: add randomness to system from rng sources" added a call to rng_get_data() from the hwrng_register() function. However, some rng devices need initialization before data can be read from them. Also, the virtio-rng device does not behave properly when this call is made in its probe() routine - the virtio core sets the DRIVER_OK status bit only on a successful

Amit, Kees, On Wed, Jul 09, 2014 at 06:55:24PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [09:17:37], Jason Cooper wrote: > > On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > > > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > > > Commit d9e7972619334

Amit, Kees, On Wed, Jul 09, 2014 at 06:55:24PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [09:17:37], Jason Cooper wrote: > > On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > > > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > > > Commit d9e7972619334

v3: - Kees Cook pointed out a weird side-effect: devices which have ->init() registered get their randomness added to the system each time they're switched in, but devices that don't have the init callback don't contribute to system randomness more than once. The weirdness is resolved here by using the randomness each time hwrng_init() is attempted, irrespective of

v3: - Kees Cook pointed out a weird side-effect: devices which have ->init() registered get their randomness added to the system each time they're switched in, but devices that don't have the init callback don't contribute to system randomness more than once. The weirdness is resolved here by using the randomness each time hwrng_init() is attempted, irrespective of

If we read hwrng by long-running dd process, it takes too much cpu time. When we check hwrng attributes from sysfs by cat, it gets stuck. The problem can only be reproduced with non-smp guest with slow backend. This patchset changed hwrng core to always delay 10 jiffies, cat process have chance to execute protected code, the problem is resolved. Thanks. Amos Kong (2): virtio-rng cleanup: move

If we read hwrng by long-running dd process, it takes too much cpu time. When we check hwrng attributes from sysfs by cat, it gets stuck. The problem can only be reproduced with non-smp guest with slow backend. This patchset changed hwrng core to always delay 10 jiffies, cat process have chance to execute protected code, the problem is resolved. Thanks. Amos Kong (2): virtio-rng cleanup: move

On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > This commit makes the call to rng_get_data() depend on no

On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > This commit makes the call to rng_get_data() depend on no

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

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

v2: - this now separates both the patches; the virtio-rng fix is self-contained - re-work hwrng core to fetch randomness at device init time if ->init() is registered by the device, instead of not calling it at all. - virtio-rng: introduce a probe_done bool to ensure we don't ask host for data before successful probe Hi, When booting a recent kernel under KVM with the virtio-rng

v2: - this now separates both the patches; the virtio-rng fix is self-contained - re-work hwrng core to fetch randomness at device init time if ->init() is registered by the device, instead of not calling it at all. - virtio-rng: introduce a probe_done bool to ensure we don't ask host for data before successful probe Hi, When booting a recent kernel under KVM with the virtio-rng

Hi Amos, I'm a libvirt QE, and I can not understand the setting on libvirt.org for rng device. Could you please help to explain a little? (The xml in https://libvirt.org/formatdomain.html#elementsRng) <devices> <rng model='virtio'> <rate period="2000" bytes="1234"/> <backend model='random'>/dev/random</backend>

Hi, When booting a recent kernel under KVM with the virtio-rng device enabled, the boot process was stalling. Bisect pointed to a commit made during the 3.15 window to fetch randomness from newly-registered devices in the hwrng core. The details are in the patches. I considered a couple of approaches, but basing on the init() function being registered, as is done in patch 1 here, seems like

Hi, When booting a recent kernel under KVM with the virtio-rng device enabled, the boot process was stalling. Bisect pointed to a commit made during the 3.15 window to fetch randomness from newly-registered devices in the hwrng core. The details are in the patches. I considered a couple of approaches, but basing on the init() function being registered, as is done in patch 1 here, seems like

On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > Hi Jason, > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > added a call to rng_get_data() from the hwrng_register() function. > > However, some rng devices need initialization before data can be read > >

On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > Hi Jason, > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > added a call to rng_get_data() from the hwrng_register() function. > > However, some rng devices need initialization before data can be read > >