linux-kernel - Re: [kvm-unit-tests PATCH] x86: Increase the timeout for vmx_pf_{vpid/no_vpid/invvpid}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6fltlvsnlbqyw3sme2zamsxp2u54tkoauydeoq2v3rri6r2uja@lmxwn57ll5ta>
Date: Mon, 5 Jan 2026 18:23:41 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, 
	Andrew Jones <andrew.jones@...ux.dev>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [kvm-unit-tests PATCH] x86: Increase the timeout for
 vmx_pf_{vpid/no_vpid/invvpid}_test

On Mon, Jan 05, 2026 at 09:54:13AM -0800, Sean Christopherson wrote:
> On Fri, Jan 02, 2026, Yosry Ahmed wrote:
> > When running the tests on some older CPUs (e.g. Skylake) on a kernel
> > with some debug config options enabled (e.g. CONFIG_DEBUG_VM,
> > CONFIG_PROVE_LOCKING, ..), the tests timeout. In this specific setup,
> > the tests take between 4 and 5 minutes, so pump the timeout from 4 to 6
> > minutes.
> 
> Ugh.  Can anyone think of a not-insane way to skip these tests when running in
> an environment that is going to be sloooooow?  Because (a) a 6 minute timeout
> could very well hide _real_ KVM bugs, e.g. if is being too aggressive with TLB
> flushes (speaking from experience) and (b) running a 5+ minute test is a likely
> a waste of time/resources.

The definition of a slow enviroment is also very dynamic, I don't think
we want to play whack-a-mole with config options or runtime knobs that
would make the tests slow.

I don't like just increasing the timeout either, but the tests are slow
even without these specific config options. They only make them a little
bit slower, enough to consistently reproduce the timeout.

I grabbed an Icelake machine With v6.18 (without the debug config
options mentioned above) and ran a couple of them (I still have some
debug config options enabled like CONFIG_SLUB_DEBUG, but I suspect some
of these are enabled by default):

# time ./vmx_pf_invvpid_test <<<y
...
PASS vmx_pf_invvpid_test (38338679 tests)

real	4m28.907s
user	2m40.198s
sys	1m47.991s

# time ./vmx_pf_vpid_test <<<y
...
PASS vmx_pf_vpid_test (38338679 tests)

real	4m21.043s
user	2m39.916s
sys	1m40.416s

This is also acknowledged by commit ca785dae0dd3 ("vmx: separate VPID
tests"), which introduced the separate targets to increase the timeout.
It mentions the 3 tests taking 12m (so roughly 4m each).  I think the
chosen 4m timeout just had very litle margin. We can make the timeout
5m, but I suspect we may still hit that on some setups (on Skylake with
the debug options, some of the tests take 4m 50s).

> 
> > Signed-off-by: Yosry Ahmed <yosry.ahmed@...ux.dev>
> > ---
> >  x86/unittests.cfg | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/x86/unittests.cfg b/x86/unittests.cfg
> > index 522318d32bf6..bb2b9f033b11 100644
> > --- a/x86/unittests.cfg
> > +++ b/x86/unittests.cfg
> > @@ -427,7 +427,7 @@ test_args = "vmx_pf_vpid_test"
> >  qemu_params = -cpu max,+vmx
> >  arch = x86_64
> >  groups = vmx nested_exception nodefault
> > -timeout = 240
> > +timeout = 360
> >  
> >  [vmx_pf_invvpid_test]
> >  file = vmx.flat
> > @@ -435,7 +435,7 @@ test_args = "vmx_pf_invvpid_test"
> >  qemu_params = -cpu max,+vmx
> >  arch = x86_64
> >  groups = vmx nested_exception nodefault
> > -timeout = 240
> > +timeout = 360
> >  
> >  [vmx_pf_no_vpid_test]
> >  file = vmx.flat
> > @@ -443,7 +443,7 @@ test_args = "vmx_pf_no_vpid_test"
> >  qemu_params = -cpu max,+vmx
> >  arch = x86_64
> >  groups = vmx nested_exception nodefault
> > -timeout = 240
> > +timeout = 360
> >  
> >  [vmx_pf_exception_test_reduced_maxphyaddr]
> >  file = vmx.flat
> > -- 
> > 2.52.0.351.gbe84eed79e-goog
> >