linux-kernel - Re: [RFC][PATCH] KVM: Remove HIGH_RES

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zs97wp2-vIRjgk-e@google.com>
Date: Wed, 28 Aug 2024 12:34:26 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, kvm@...r.kernel.org, 
	Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, 
	"x86@...nel.org" <x86@...nel.org>, Joel Fernandes <joel@...lfernandes.org>, 
	Suleiman Souhlal <ssouhlal@...ebsd.org>, Vineeth Pillai <vineeth@...byteword.org>, 
	Borislav Petkov <bp@...en8.de>, Anna-Maria Behnsen <anna-maria@...utronix.de>, 
	Peter Zijlstra <peterz@...radead.org>, Viresh Kumar <viresh.kumar@...aro.org>, 
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC][PATCH] KVM: Remove HIGH_RES_TIMERS dependency

On Wed, Aug 21, 2024, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@...dmis.org>
> 
> Commit 92b5265d38f6a ("KVM: Depend on HIGH_RES_TIMERS") added a dependency
> to high resolution timers with the comment:
> 
>     KVM lapic timer and tsc deadline timer based on hrtimer,
>     setting a leftmost node to rb tree and then do hrtimer reprogram.
>     If hrtimer not configured as high resolution, hrtimer_enqueue_reprogram
>     do nothing and then make kvm lapic timer and tsc deadline timer fail.
> 
> That was back in 2012, where hrtimer_start_range_ns() would do the
> reprogramming with hrtimer_enqueue_reprogram(). But as that was a nop with
> high resolution timers disabled, this did not work. But a lot has changed
> in the last 12 years.
> 
> For example, commit 49a2a07514a3a ("hrtimer: Kick lowres dynticks targets on
> timer enqueue") modifies __hrtimer_start_range_ns() to work with low res
> timers. There's been lots of other changes that make low res work.
> 
> I added this change to my main server that runs all my VMs (my mail
> server, my web server, my ssh server) and disabled HIGH_RES_TIMERS and the
> system has been running just fine for over a month.
> 
> ChromeOS has tested this before as well, and it hasn't seen any issues with
> running KVM with high res timers disabled.

Can you provide some background on why this is desirable, and what the effective
tradeoffs are?  Mostly so that future users have some chance of making an
informed decision.  Realistically, anyone running with HIGH_RES_TIMERS=n is likely
already aware of the tradeoffs, but it'd be nice to capture the info here.

> Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.org>
> ---
>  arch/x86/kvm/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 472a1537b7a9..c65127e796a9 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -19,7 +19,6 @@ if VIRTUALIZATION
>  
>  config KVM
>  	tristate "Kernel-based Virtual Machine (KVM) support"
> -	depends on HIGH_RES_TIMERS

I did some very basic testing and nothing exploded on me either.  So long as
nothing in the host catches fire, I don't see a good reason to make high resolution
timers a hard requirement.

My only concern is that this could, at least in theory, result in people
unintentionally breaking their setups, but that seems quite unlikely.

One thought would be to require the user to enable EXPERT in order to break the
HIGH_RES_TIMERS dependency.  In practice, I doubt that will be much of a deterrent
since (IIRC) many distros ship with EXPERT=y.  But it would at least document that
using KVM x86 without HIGH_RES_TIMERS may come with caveats.  E.g.

	depends on HIGH_RES_TIMERS || EXPERT