Sean Christopherson <[email protected]> writes: > On Tue, Sep 22, 2026, Ritesh Harjani (IBM) wrote: >> hardware_disable_test forks several VMs (NR_IERATIONS=512). This patch >> limits that number to 4 when we know that we are running in constraint >> host environment. The number 4 is just a safe minimum when >> kvm_arch_vm_create_may_enomem() can be true. > > Please actually explain *why* this is necessary, and where the magic '4' > comes. > I assume there's some system-wide resource at play?
Yes, this is the similar issue of limited resources at L0 for nested-v2 case. This test actually forks and each child creates a VM. Here, the parent queues the SIGKILL for the child, however it does not waitpid before the next fork. That means the VM can still be eating the guest management space at L0 for the nested-v2 guests (until the VM is completely destroyed). I agree the number 4 is a bit ugly here. It was just a safe limit. I was able to spawn multiple VMs ofcourse - but for the sake of enabling this test I went with some safe minimum. BTW, since you suggested that in the initial enablement of the kvm PPC selftests, we need not land this hardware_disable_test, so I will skip this for now. -ritesh
