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

[fuqiang wang <fuqiang.wng@gmail.com>]

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