| Message ID | 20220927164920.1502219-1-peter.maydell@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] target/arm/kvm: Retry KVM_CREATE_VM call if it fails EINTR | expand |
diff --git a/target/arm/kvm.c b/target/arm/kvm.c index e5c1bd50d29..356199c9e25 100644 --- a/target/arm/kvm.c +++ b/target/arm/kvm.c @@ -79,7 +79,9 @@ bool kvm_arm_create_scratch_host_vcpu(const uint32_t *cpus_to_try, if (max_vm_pa_size < 0) { max_vm_pa_size = 0; } - vmfd = ioctl(kvmfd, KVM_CREATE_VM, max_vm_pa_size); + do { + vmfd = ioctl(kvmfd, KVM_CREATE_VM, max_vm_pa_size); + } while (vmfd == -1 && errno == -EINTR); if (vmfd < 0) { goto err; }
Occasionally the KVM_CREATE_VM ioctl can return EINTR, even though there is no pending signal to be taken. In commit 94ccff13382055 we added a retry-on-EINTR loop to the KVM_CREATE_VM call in the generic KVM code. Adopt the same approach for the use of the ioctl in the Arm-specific KVM code (where we use it to create a scratch VM for probing for various things). For more information, see the mailing list thread: https://lore.kernel.org/qemu-devel/8735e0s1zw.wl-maz@kernel.org/ Reported-by: Vitaly Chikunov <vt@altlinux.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- The view in the thread seems to be that this is a kernel bug (because in QEMU's case there shouldn't be a signal to be delivered at this point because of our signal handling strategy); so I've adopted the same "just retry-on-EINTR for this specific ioctl" approach that commit 94ccff13 did, rather than, for instance, something wider like "make kvm_ioctl() and friends always retry on EINTR". v2: correctly check for -1 and errno is EINTR... --- target/arm/kvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)