linux-kernel - Re: [PATCH] x86/xen/time: Reduce Xen timer tick

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZnFL_0ihWiI7Yaf0@macbook>
Date: Tue, 18 Jun 2024 10:57:35 +0200
From: Roger Pau Monné <roger.pau@...rix.com>
To: Frediano Ziglio <frediano.ziglio@...ud.com>
Cc: Jan Beulich <jbeulich@...e.com>, "H. Peter Anvin" <hpa@...or.com>,
	x86@...nel.org, Dave Hansen <dave.hansen@...ux.intel.com>,
	Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/xen/time: Reduce Xen timer tick

On Tue, Jun 18, 2024 at 09:37:08AM +0100, Frediano Ziglio wrote:
> On Mon, Jun 17, 2024 at 3:37 PM Roger Pau Monné <roger.pau@...rix.com> wrote:
> >
> > On Mon, Jun 17, 2024 at 04:22:21PM +0200, Jan Beulich wrote:
> > > On 17.06.2024 16:13, Frediano Ziglio wrote:
> > > > Current timer tick is causing some deadline to fail.
> > > > The current high value constant was probably due to an old
> > > > bug in the Xen timer implementation causing errors if the
> > > > deadline was in the future.
> > > > This was fixed in Xen commit:
> > > > 19c6cbd90965 xen/vcpu: ignore VCPU_SSHOTTMR_future
> > >
> > > And then newer kernels are no longer reliably usable on Xen older than
> > > this?
> >
> > I think this should reference the Linux commit that removed the usage
> > of VCPU_SSHOTTMR_future on Linux itself, not the change that makes Xen
> > ignore the flag.
> >
> 
> Yes, Linux kernel stopped using this flag since 2016 with commit
> c06b6d70feb32d28f04ba37aa3df17973fd37b6b, "xen/x86: don't lose event
> interrupts", I'll add it in the commit message.
> 
> > > > --- a/arch/x86/xen/time.c
> > > > +++ b/arch/x86/xen/time.c
> > > > @@ -30,7 +30,7 @@
> > > >  #include "xen-ops.h"
> > > >
> > > >  /* Minimum amount of time until next clock event fires */
> > > > -#define TIMER_SLOP 100000
> > > > +#define TIMER_SLOP 1000
> > >
> > > It may be just the lack of knowledge of mine towards noadays's Linux'es
> > > time handling, but the change of a value with this name and thus
> > > commented doesn't directly relate to "timer tick" rate. Could you maybe
> > > help me see the connection?
> >
> > The TIMER_SLOP define is used in min_delta_{ns,ticks} field, and I
> > think this is wrong.
> >
> > The min_delta_ns for the Xen timer is 1ns.  If Linux needs some
> > greater min delta than what the timer interface supports it should be
> > handled in the generic timer code, not open coded at the definition of
> > possibly each timer implementation.
> >
> 
> I think this is done to reduce potential event handling frequency, in
> some other part of timer code (in kernel/time/clockevents.c) there's a
> comment "Deltas less than 1usec are pointless noise".

Then why does the interface allow for timers having a resolution up to
1ns then?

> I think it's hard for a software to get a frequency so high so I
> didn't propose 1ns.
> What are you suggesting? To put 1ns and see what happens? Is there any
> proper test code for this?

The Xen timer interface has a resolution of 1ns, and the Linux
structures that describe timers also support a 1ns resolution.  I can
perfectly understand that deltas of 1ns make no sense, but given how
the Xen timer works those won't be a problem.  The interrupt will get
injected strictly after the hypercall to setup the timer, because by
the time Xen processes the delta it will most likely have already
expired.

Forcing every timer to setup a minimal delta of 1usec is pointless.
It either needs to be done in the generic code, or the interface to
register timers needs to be adjusted to allow for a minimum resolution
of 1usec.

Thanks, Roger.