similar to: [PATCH 0/3] virtio-rng: contribute to early randomness requests

v2: - update patch 3 to store the hwrng_register_done bool per-device rather than global - add patch 2 that re-arranges struct elems for better packing. Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 3), with Herbert's idea of using the scan routine. Patch 4 reverts the previous restriction, which no longer applies, to not send

v2: - update patch 3 to store the hwrng_register_done bool per-device rather than global - add patch 2 that re-arranges struct elems for better packing. Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 3), with Herbert's idea of using the scan routine. Patch 4 reverts the previous restriction, which no longer applies, to not send

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the

On Mon, Jul 21, 2014 at 05:15:51PM +0530, Amit Shah wrote: > Instead of calling hwrng_register() in the probe routing, call it in the > scan routine. This ensures that when hwrng_register() is successful, > and it requests a few random bytes to seed the kernel's pool at init, > we're ready to service that request. > > This will also enable us to remove the workaround

On Mon, Jul 21, 2014 at 05:15:51PM +0530, Amit Shah wrote: > Instead of calling hwrng_register() in the probe routing, call it in the > scan routine. This ensures that when hwrng_register() is successful, > and it requests a few random bytes to seed the kernel's pool at init, > we're ready to service that request. > > This will also enable us to remove the workaround

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the

Hello, This series introduces a way to allow devices to contribute to initial system randomness after a certain delay. Specifically, the virtio-rng device can contribute initial randomness only after a successful probe(). A delayed workqueue item is queued in the system queue to fetch this randomness if the device indicates it's capable of contributing only after a delay, via the new

Hello, This series introduces a way to allow devices to contribute to initial system randomness after a certain delay. Specifically, the virtio-rng device can contribute initial randomness only after a successful probe(). A delayed workqueue item is queued in the system queue to fetch this randomness if the device indicates it's capable of contributing only after a delay, via the new

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

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

On (Wed) 06 Aug 2014 [16:05:41], Amos Kong wrote: > On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote: > > When we try to hot-remove a busy virtio-rng device from QEMU monitor, > > the device can't be hot-removed. Because virtio-rng driver hangs at > > wait_for_completion_killable(). > > > > This patch fixed the hang by completing have_data completion

On (Wed) 06 Aug 2014 [16:05:41], Amos Kong wrote: > On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote: > > When we try to hot-remove a busy virtio-rng device from QEMU monitor, > > the device can't be hot-removed. Because virtio-rng driver hangs at > > wait_for_completion_killable(). > > > > This patch fixed the hang by completing have_data completion

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

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the

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