linux-kernel - Re: [PATCH RESEND] avoid hv timer fallback to sw timer if delay exceeds period

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: <5f35565e-ddda-4b3e-954d-7f865baede05@gmail.com>
Date: Tue, 21 Oct 2025 23:37:57 +0800
From: fuqiang wang <fuqiang.wng@...il.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner
 <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org, "H . Peter Anvin" <hpa@...or.com>,
 Maxim Levitsky <mlevitsk@...hat.com>, kvm@...r.kernel.org,
 linux-kernel@...r.kernel.org, yu chen <chen.yu@...ystack.com>,
 dongxu zhang <dongxu.zhang@...ystack.com>
Subject: Re: [PATCH RESEND] avoid hv timer fallback to sw timer if delay
 exceeds period

On 10/17/25 11:59 PM, Sean Christopherson wrote:

>> ====
>> IMHO
>> ====
>>
>> 1. for period timer
>> ===================
>>
>> I think for periodic timers emulation, the expiration time is already adjusted
>> to compensate for the delays introduced by timer emulation, so don't need this
>> feature to adjust again. But after use the feature, the first timer expiration
>> may be relatively accurate.
>>
>> E.g., At time 0, start a periodic task (period: 10,000 ns) with a simulated
>> delay of 100 ns.
>>
>> With this feature enabled and reasonably accurate prediction, the expiration
>> time set seen by the guest are: 10000, 20000, 30000...
>>
>> With this feature not enabled, the expiration times set: 10100, 20100, 30100...
>>
>> But IMHO, for periodic timers, accuracy of the period seems to be the main
>> concern, because it does not frequently start and stop. The incorrect period
>> caused by the first timer expiration can be ignored.
>
> I agree it's superfluous, but applying the advancement also does no harm, and
> avoiding it would be moreeffort than simply letting KVM predict the first expiration.
>

Yes, that’s indeed the case.

> KVM unconditionally emulates TSC-deadline mode, and AFAIK every real-world kernel
> prefers TSC-deadline over one-shot, and so in practice the benefits of applying
> the advancement to one-shot hrtimers.  That was also the way the world was headed
> back when Marcelo first implemented the support.  I don't know for sure why the
> initial implementation targeted only TSC-deadline mode, but I think it's safe to
> assume that the use case Marcelo was targeting exclusively used TSC-deadline.

Yes, it appears that focusing on TSC-deadline emulation fits the current use
cases.

>
> I'm not entirely opposed to playing the advancement games with one-shot hrtimers,
> but it's also not clear to me that it's worth doing.  E.g. supporting one-shot
> hrtimers would likely require a bit of extra complexity to juggle the different
> time domains.  And if the only use cases that are truly sensitive to timer
> programming latency exclusively use TSC-deadline mode (because one-shot mode is
> inherently "fuzzy"), then any amount of extra complexity is effectively dead weight.
>
>> should not be applied to:
>> sw/hv period
>
> I wouldn't say "should not be applied to", I think it's more "doesn't provide much
> benefit to".

Thanks again for your clear explanation and insights. This really helped me
understand the design choices better. :)

Regards,
fuqiang