target/arm/kvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
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(-)
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;
}
--
2.25.1
Hi Peter, On 9/27/22 18:49, Peter Maydell wrote: > 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(-) > > 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); shouldn't it be errno == EINTR? Eric > if (vmfd < 0) { > goto err; > }
On Tue, 27 Sept 2022 at 18:07, Eric Auger <eric.auger@redhat.com> wrote: > > Hi Peter, > > On 9/27/22 18:49, Peter Maydell wrote: > > 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(-) > > > > 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); > shouldn't it be errno == EINTR? Augh. Yes. -- PMM
© 2016 - 2024 Red Hat, Inc.