tools/testing/selftests/kvm/memslot_perf_test.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
When memslot_perf_test is run on qemu, sometimes the RW subtest fails
due to sigalarm, indicating that the guest sync did not finish within
the expected duration of 10 seconds. Since the current timeout value is
itself a bump up from the original 2s, making the host timeout value
configurable via a new command line parameter. Now the test can be
invoked with '-a' argument to run the test with a suitable host timeout
value.
Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
---
tools/testing/selftests/kvm/memslot_perf_test.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/kvm/memslot_perf_test.c b/tools/testing/selftests/kvm/memslot_perf_test.c
index 5087d082c4b0..432dbb5fde82 100644
--- a/tools/testing/selftests/kvm/memslot_perf_test.c
+++ b/tools/testing/selftests/kvm/memslot_perf_test.c
@@ -111,6 +111,7 @@ struct sync_area {
*/
static_assert(ATOMIC_BOOL_LOCK_FREE == 2, "atomic bool is not lockless");
+static int wait_timeout = 10;
static sem_t vcpu_ready;
static bool map_unmap_verify;
@@ -418,7 +419,7 @@ static bool _guest_should_exit(void)
*/
static noinline void host_perform_sync(struct sync_area *sync)
{
- alarm(10);
+ alarm(wait_timeout);
atomic_store_explicit(&sync->sync_flag, true, memory_order_release);
while (atomic_load_explicit(&sync->sync_flag, memory_order_acquire))
@@ -900,7 +901,7 @@ static void help(char *name, struct test_args *targs)
{
int ctr;
- pr_info("usage: %s [-h] [-v] [-d] [-s slots] [-f first_test] [-e last_test] [-l test_length] [-r run_count]\n",
+ pr_info("usage: %s [-h] [-v] [-d] [-s slots] [-f first_test] [-e last_test] [-l test_length] [-r run_count] [-a wait_timeout]\n",
name);
pr_info(" -h: print this help screen.\n");
pr_info(" -v: enable verbose mode (not for benchmarking).\n");
@@ -916,6 +917,8 @@ static void help(char *name, struct test_args *targs)
targs->seconds);
pr_info(" -r: specify the number of runs per test (currently: %i)\n",
targs->runs);
+ pr_info(" -a: specify the number of seconds for host wait timeout (currently: %i)\n",
+ wait_timeout);
pr_info("\nAvailable tests:\n");
for (ctr = 0; ctr < NTESTS; ctr++)
@@ -964,7 +967,7 @@ static bool parse_args(int argc, char *argv[],
uint32_t max_mem_slots;
int opt;
- while ((opt = getopt(argc, argv, "hvdqs:f:e:l:r:")) != -1) {
+ while ((opt = getopt(argc, argv, "hvdqs:f:e:l:r:a:")) != -1) {
switch (opt) {
case 'h':
default:
@@ -1007,6 +1010,9 @@ static bool parse_args(int argc, char *argv[],
case 'r':
targs->runs = atoi_positive("Runs per test", optarg);
break;
+ case 'a':
+ wait_timeout = atoi_positive("Host wait timeout", optarg);
+ break;
}
}
--
2.43.0On Thu, Apr 02, 2026, Mayuresh Chitale wrote:
> When memslot_perf_test is run on qemu, sometimes the RW subtest fails
For posterity, can you elaborate on exactly what "is run on qemu" means?
> @@ -900,7 +901,7 @@ static void help(char *name, struct test_args *targs)
> {
> int ctr;
>
> - pr_info("usage: %s [-h] [-v] [-d] [-s slots] [-f first_test] [-e last_test] [-l test_length] [-r run_count]\n",
> + pr_info("usage: %s [-h] [-v] [-d] [-s slots] [-f first_test] [-e last_test] [-l test_length] [-r run_count] [-a wait_timeout]\n",
> name);
> pr_info(" -h: print this help screen.\n");
> pr_info(" -v: enable verbose mode (not for benchmarking).\n");
> @@ -916,6 +917,8 @@ static void help(char *name, struct test_args *targs)
> targs->seconds);
> pr_info(" -r: specify the number of runs per test (currently: %i)\n",
> targs->runs);
> + pr_info(" -a: specify the number of seconds for host wait timeout (currently: %i)\n",
> + wait_timeout);
Why '-a'? '-t' is available, and seems more intuitive for --timeout.
> pr_info("\nAvailable tests:\n");
> for (ctr = 0; ctr < NTESTS; ctr++)
> @@ -964,7 +967,7 @@ static bool parse_args(int argc, char *argv[],
> uint32_t max_mem_slots;
> int opt;
>
> - while ((opt = getopt(argc, argv, "hvdqs:f:e:l:r:")) != -1) {
> + while ((opt = getopt(argc, argv, "hvdqs:f:e:l:r:a:")) != -1) {
> switch (opt) {
> case 'h':
> default:
> @@ -1007,6 +1010,9 @@ static bool parse_args(int argc, char *argv[],
> case 'r':
> targs->runs = atoi_positive("Runs per test", optarg);
> break;
> + case 'a':
> + wait_timeout = atoi_positive("Host wait timeout", optarg);
> + break;
> }
> }
>
> --
> 2.43.0
>
On Tue, Apr 7, 2026 at 4:31 AM Sean Christopherson <seanjc@google.com> wrote:
>
> On Thu, Apr 02, 2026, Mayuresh Chitale wrote:
> > When memslot_perf_test is run on qemu, sometimes the RW subtest fails
>
> For posterity, can you elaborate on exactly what "is run on qemu" means?
Sure.
>
> > @@ -900,7 +901,7 @@ static void help(char *name, struct test_args *targs)
> > {
> > int ctr;
> >
> > - pr_info("usage: %s [-h] [-v] [-d] [-s slots] [-f first_test] [-e last_test] [-l test_length] [-r run_count]\n",
> > + pr_info("usage: %s [-h] [-v] [-d] [-s slots] [-f first_test] [-e last_test] [-l test_length] [-r run_count] [-a wait_timeout]\n",
> > name);
> > pr_info(" -h: print this help screen.\n");
> > pr_info(" -v: enable verbose mode (not for benchmarking).\n");
> > @@ -916,6 +917,8 @@ static void help(char *name, struct test_args *targs)
> > targs->seconds);
> > pr_info(" -r: specify the number of runs per test (currently: %i)\n",
> > targs->runs);
> > + pr_info(" -a: specify the number of seconds for host wait timeout (currently: %i)\n",
> > + wait_timeout);
>
> Why '-a'? '-t' is available, and seems more intuitive for --timeout.
I was thinking 'a' for 'alarm' but 't' is better :).
>
> > pr_info("\nAvailable tests:\n");
> > for (ctr = 0; ctr < NTESTS; ctr++)
> > @@ -964,7 +967,7 @@ static bool parse_args(int argc, char *argv[],
> > uint32_t max_mem_slots;
> > int opt;
> >
> > - while ((opt = getopt(argc, argv, "hvdqs:f:e:l:r:")) != -1) {
> > + while ((opt = getopt(argc, argv, "hvdqs:f:e:l:r:a:")) != -1) {
> > switch (opt) {
> > case 'h':
> > default:
> > @@ -1007,6 +1010,9 @@ static bool parse_args(int argc, char *argv[],
> > case 'r':
> > targs->runs = atoi_positive("Runs per test", optarg);
> > break;
> > + case 'a':
> > + wait_timeout = atoi_positive("Host wait timeout", optarg);
> > + break;
> > }
> > }
> >
> > --
> > 2.43.0
> >
On 2.04.2026 12:29, Mayuresh Chitale wrote: > When memslot_perf_test is run on qemu, sometimes the RW subtest fails > due to sigalarm, indicating that the guest sync did not finish within > the expected duration of 10 seconds. Since the current timeout value is > itself a bump up from the original 2s, making the host timeout value > configurable via a new command line parameter. Now the test can be > invoked with '-a' argument to run the test with a suitable host timeout > value. > > Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com> > --- Out of curiosity: which KVM-enabled setup takes more than 10 seconds to run that RW test? Does it have like, multiple levels of nesting? When I wrote that test I calibrated it on a mid-range x86 machine, where one iteration took on the order of 0.01 s. 10 s time limit per iteration is already three orders of magnitude slower than that. Otherwise, the patch looks sensible to me. Thanks, Maciej
On Thu, Apr 2, 2026 at 11:50 PM Maciej S. Szmigiero <mail@maciej.szmigiero.name> wrote: > > On 2.04.2026 12:29, Mayuresh Chitale wrote: > > When memslot_perf_test is run on qemu, sometimes the RW subtest fails > > due to sigalarm, indicating that the guest sync did not finish within > > the expected duration of 10 seconds. Since the current timeout value is > > itself a bump up from the original 2s, making the host timeout value > > configurable via a new command line parameter. Now the test can be > > invoked with '-a' argument to run the test with a suitable host timeout > > value. > > > > Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com> > > --- > > Out of curiosity: which KVM-enabled setup takes more than 10 seconds > to run that RW test? > Does it have like, multiple levels of nesting? No. It was run on the Qemu Risc-V Virt machine. > > When I wrote that test I calibrated it on a mid-range x86 machine, > where one iteration took on the order of 0.01 s. > > 10 s time limit per iteration is already three orders of magnitude > slower than that. > > Otherwise, the patch looks sensible to me. > > Thanks, > Maciej >
On Thu, Apr 02, 2026, Maciej S. Szmigiero wrote: > On 2.04.2026 12:29, Mayuresh Chitale wrote: > > When memslot_perf_test is run on qemu, sometimes the RW subtest fails > > due to sigalarm, indicating that the guest sync did not finish within > > the expected duration of 10 seconds. Since the current timeout value is > > itself a bump up from the original 2s, making the host timeout value > > configurable via a new command line parameter. Now the test can be > > invoked with '-a' argument to run the test with a suitable host timeout > > value. > > > > Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com> > > --- > > Out of curiosity: which KVM-enabled setup takes more than 10 seconds > to run that RW test? Hmm, I assume "run on qemu" means running in a VM that's fully emulated by QEMU? That would probably explain why it's so slow? > Does it have like, multiple levels of nesting? > > When I wrote that test I calibrated it on a mid-range x86 machine, > where one iteration took on the order of 0.01 s. > > 10 s time limit per iteration is already three orders of magnitude > slower than that. > > Otherwise, the patch looks sensible to me. > > Thanks, > Maciej >
On Tue, Apr 7, 2026 at 4:30 AM Sean Christopherson <seanjc@google.com> wrote: > > On Thu, Apr 02, 2026, Maciej S. Szmigiero wrote: > > On 2.04.2026 12:29, Mayuresh Chitale wrote: > > > When memslot_perf_test is run on qemu, sometimes the RW subtest fails > > > due to sigalarm, indicating that the guest sync did not finish within > > > the expected duration of 10 seconds. Since the current timeout value is > > > itself a bump up from the original 2s, making the host timeout value > > > configurable via a new command line parameter. Now the test can be > > > invoked with '-a' argument to run the test with a suitable host timeout > > > value. > > > > > > Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com> > > > --- > > > > Out of curiosity: which KVM-enabled setup takes more than 10 seconds > > to run that RW test? > > Hmm, I assume "run on qemu" means running in a VM that's fully emulated by QEMU? > That would probably explain why it's so slow? Yes. thats correct. I can update the commit message to reflect that. > > > Does it have like, multiple levels of nesting? > > > > When I wrote that test I calibrated it on a mid-range x86 machine, > > where one iteration took on the order of 0.01 s. > > > > 10 s time limit per iteration is already three orders of magnitude > > slower than that. > > > > Otherwise, the patch looks sensible to me. > > > > Thanks, > > Maciej > >
On 7.04.2026 12:21, Mayuresh Chitale wrote: > On Tue, Apr 7, 2026 at 4:30 AM Sean Christopherson <seanjc@google.com> wrote: >> >> On Thu, Apr 02, 2026, Maciej S. Szmigiero wrote: >>> On 2.04.2026 12:29, Mayuresh Chitale wrote: >>>> When memslot_perf_test is run on qemu, sometimes the RW subtest fails >>>> due to sigalarm, indicating that the guest sync did not finish within >>>> the expected duration of 10 seconds. Since the current timeout value is >>>> itself a bump up from the original 2s, making the host timeout value >>>> configurable via a new command line parameter. Now the test can be >>>> invoked with '-a' argument to run the test with a suitable host timeout >>>> value. >>>> >>>> Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com> >>>> --- >>> >>> Out of curiosity: which KVM-enabled setup takes more than 10 seconds >>> to run that RW test? >> >> Hmm, I assume "run on qemu" means running in a VM that's fully emulated by QEMU? >> That would probably explain why it's so slow? > > Yes. thats correct. I can update the commit message to reflect that. >> Thanks for info Mayuresh and Sean. I thought QEMU has only rudimentary SVM emulation, but apparently it's enough for KVM selftests to run. Thanks, Maciej
© 2016 - 2026 Red Hat, Inc.