virtio_random: timeout rather than blocking entropy collection

[kevans]

Summary

Some virtio-rng providers are known to ratelimit to rates below what
random(4) expects for 'fast' sources. Because we read all sources
serially, this lowers the overall quality of the pool while driving up
CPU utilization to some extent as we spend more time spinning in
virtqueue_poll().

This commit by default times out polling at 2ms. This is based on a
rough estimate of how long this should take with fortuna to avoid
impact:

10hz / RANDOM_FORTUNA_NPOOLS(32) calls = ~3ms per call at most to avoid
bringing everyone down; shave off 1ms of 'other overhead' to arrive at
2ms for the poll itself.

If we end up timing out, the next iteration will simply drop the result
on the floor -- we can't quickly know how long it's been sitting in the
now heap-allocated buffer, because it may have been enqueued on the last
read of this source in random_sources_feed().

[cem]

As mentioned earlier in the stack I don’t think this mitigation is great.

Edit: if we pursue this mitigation, we also need to poll at device unload so we can free the softc.

sys/dev/virtio/random/virtio_random.c

262

This doesn’t make sense starting at “after it’s” - ie just end the sentence at “safer to discard it.”