On Thu, Nov 05, 2020 at 03:34:01PM +0100, Ard Biesheuvel wrote: > On Thu, 5 Nov 2020 at 15:30, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote: > > > On Thu, 5 Nov 2020 at 15:03, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > > > > > That said, I'm not sure it's great to plumb this under the > > > > arch_get_random*() interfaces, e.g. given this measn that > > > > add_interrupt_randomness() will end up trapping to the host all the time > > > > when it calls arch_get_random_seed_long(). > > > > > > As it turns out, add_interrupt_randomness() isn't actually used on ARM. > > > > It's certainly called on arm64, per a warning I just hacked in: [...] > > ... and I couldn't immediately spot why 32-bit arm would be different. > > Hmm, I actually meant both arm64 and ARM. > > Marc looked into this at my request a while ago, and I had a look > myself as well at the time, and IIRC, we both concluded that we don't > hit that code path. Darn. > > In any case, the way add_interrupt_randomness() calls > arch_get_random_seed_long() is absolutely insane, so we should try to > fix that in any case. I have no strong opinion there, and I'm happy with that getting cleaned up. Regardless, I do think it's reasonable for the common code to expect that arch_get_random_*() to be roughly as expensive as "most other instructions" (since even RNDR* is expensive the CPU might be able to do useful speculative work in the mean time), whereas a trap to the host is always liable to be expensive as no useful work can be done while the host is handling it, so I think it makes sense to distinguish the two. Thanks, Mark. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
