> CONFIG_PCI=y
> CONFIG_VIRTIO=y
> CONFIG_VIRTIO_PCI=y
> CONFIG_VIRTIO_BLK=y
> CONFIG_HW_RANDOM_VIRTIO=y
> CONFIG_CRYPTO_DEV_VIRTIO=y
> CONFIG_CRYPTO_HW=y
> CONFIG_CRYPTO_RNG2=y
> CONFIG_HW_RANDOM=y
>
> I honestly don't know which of these actually matter. I'm wondering, am I missing something?
Are you using other PCI devices successfully? Do the kernel's
bootup messages include information about having successfully
found PCI devices? That will tell you whether you need to be
looking for "config switches related to PCI in general" or "config
switches related to RNG stuff".
In particular, make sure you have
CONFIG_PCI_HOST_GENERIC=y
-- this is the switch that enables support for the virt board's PCI controller.
Yes great, thank you for the tip.. I should have been looking in dmesg for PCI stuff all along. While CONFIG_PCI_HOST_GENERIC was not set, setting it didn't help. But that did give me an error which I tracked down to this:
Starting QEMU with:
-M virt,highmem=off
...fixes the /dev/hwrng issue. That said, there's an additional problem which is that rngd takes 10-20s to initialize from /dev/hwrng.
Also, the presence of rngd doesn't seem to increase or decrease the rng throughput:
(with rngd...)
rngtest: bits received from input: 521780032
rngtest: FIPS 140-2 successes: 26071
rngtest: FIPS 140-2 failures: 18
rngtest: FIPS 140-2(2001-10-10) Monobit: 1
rngtest: FIPS 140-2(2001-10-10) Poker: 4
rngtest: FIPS 140-2(2001-10-10) Runs: 8
rngtest: FIPS 140-2(2001-10-10) Long run: 5
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=5.022; avg=37.484; max=544.957)Mibits/s
rngtest: FIPS tests speed: (min=1.690; avg=42.693; max=44.152)Mibits/s
rngtest: Program run time: 25015557 microseconds
(without rngd, presumably means not using /dev/hwrng?)
rngtest: bits received from input: 524600032
rngtest: FIPS 140-2 successes: 26213
rngtest: FIPS 140-2 failures: 17
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 3
rngtest: FIPS 140-2(2001-10-10) Runs: 6
rngtest: FIPS 140-2(2001-10-10) Long run: 8
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=6.788; avg=37.489; max=544.957)Mibits/s
rngtest: FIPS tests speed: (min=2.864; avg=43.172; max=44.564)Mibits/s
rngtest: Program run time: 25016438 microseconds
In both cases I get approximately 37Mbps in the input channel. I'm not sure if I'm interpreting the results correctly, but I take that to mean that /dev/hwrng isn't contributing to the entropy pool. Note, the host machine has plenty of entropy and the same test gets 15,000Mbps. In both the cases /proc/sys/kernel/random/entropy_avail has approximately the same value. The rngd logs show it's working correctly and adding entropy from the hwrng.
I realize this may not be a qemu issue at this point, but I am curious as to why rngd takes so long to initialize /dev/hwrng.
Wes