On Thu, Nov 07, 2024, Eric Auger wrote: > In case a KVM_REQ_VM_DEAD request was sent to a VM, subsequent > KVM ioctls will fail and cause test failure. This now happens > with an aarch64 vgic test where the kvm_vm_free() fails. Let's > add a new kvm_vm_dead_free() helper that does all the deallocation > besides the KVM_SET_USER_MEMORY_REGION2 ioctl. Please no. I don't want to bleed the kvm->vm_dead behavior all over selftests. The hack in __TEST_ASSERT_VM_VCPU_IOCTL() is there purely to provide users with a more helpful error message, it is most definitely not intended to be an "official" way to detect and react to the VM being dead. IMO, tests that intentionally result in a dead VM should assert that subsequent VM/vCPU ioctls return -EIO, and that's all. Attempting to gracefully free resources adds complexity and pollutes the core selftests APIs, with very little benefit. Marking a VM dead should be a _very_ rare event; it's not something that I think we should encourage, i.e. we shouldn't make it easier to deal with. Ideally, use of kvm_vm_dead() should be limited to things like sev_vm_move_enc_context_from(), where KVM needs to prever accessing the source VM to protect the host. IMO, the vGIC case and x86's enter_smm() are hacks. E.g. I don't see any reason why the enter_smm() case can't synthesize a triple fault. If memory utilization is a concern for the vgic_init test (which seems unlikely), I would much rather solve that problem by expanding KVM selftests support for the selftests harness so that each testcase runs as a child process. https://lore.kernel.org/all/ZjUwqEXPA5QVItyX@xxxxxxxxxx
