On Thu, Sep 01, 2022 at 06:22:05PM +0000, Sean Christopherson wrote: > On Thu, Sep 01, 2022, Ricardo Koller wrote: > > On Tue, Aug 30, 2022 at 07:01:57PM +0000, Colton Lewis wrote: > > > David Matlack <dmatlack@xxxxxxxxxx> writes: > > > > I think this is broken if !partition_vcpu_memory_access. nr_randoms > > > > (per-vCPU) should be `nr_vcpus * vcpu_memory_bytes >> vm->page_shift`. > > > > > > > > > Agree it will break then and should not. But allocating that many more > > > random numbers may eat too much memory. In a test with 64 vcpus, it would > > > try to allocate 64x64 times as many random numbers. I'll try it but may > > > need something different in that case. > > > > You might want to reconsider the idea of using a random number generator > > inside the guest. IRC the reasons against it were: quality of the random > > numbers, and that some random generators use floating-point numbers. I > > don't think the first one is a big issue. The second one might be an > > issue if we want to generate non-uniform distributions (e.g., poisson); > > but not a problem for now. > > I'm pretty I had coded up a pseudo-RNG framework for selftests at one point, but > I cant find the code in my morass of branches and stashes :-( Here's an option that was once proposed by Alex Bennee for kvm-unit-tests. (Someday we need to revisit that MTTCG series...) https://gitlab.com/rhdrjones/kvm-unit-tests/-/commit/2fc51790577c9f91214f72ef51ee5d0e8bbb1b7e Thanks, drew > > Whatever we do, make sure the randomness and thus any failures are easily > reproducible, i.e. the RNG needs to be seeded pseudo-RNG, not fully random.
