Re: [PATCH 1/2] xen/x86: don't send IPI to sync TSC when it is reliable

[Stefano Stabellini <stefano.stabellini@xxxxxxx>]

On Tue, 8 Jul 2025, Jan Beulich wrote:
> On 08.07.2025 02:07, Stefano Stabellini wrote:
> > On real time configuration with the null scheduler, we shouldn't
> > interrupt the guest execution unless strictly necessary: the guest could
> > be a real time guest (e.g. FreeRTOS) and interrupting its execution
> > could lead to a missed deadline.
> > 
> > The principal source of interruptions is IPIs. Remove the unnecessary
> > IPI on all physical CPUs to sync the TSC when the TSC is known to be
> > reliable.
> 
> If it had been truly unnecessary for all the time, I'm sure someone would
> have suggested to get rid of the overhead.

I am not so sure someone else would have suggested it given that Xen on
x86 has been mostly used on the datacenter where real-time is not a
requirement. 


> IOW I think there is more to be
> said as to this being correct / safe, including in any corner cases.
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> > ---
> >  xen/arch/x86/time.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> > index 59129f419d..bfd022174a 100644
> > --- a/xen/arch/x86/time.c
> > +++ b/xen/arch/x86/time.c
> > @@ -2303,6 +2303,10 @@ static void cf_check time_calibration(void *unused)
> >          local_irq_enable();
> >      }
> >  
> > +    if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
> > +         boot_cpu_has(X86_FEATURE_TSC_RELIABLE) )
> > +        return;
> 
> This would render the (first of the two) invocation(s) of the function from
> verify_tsc_reliability() (largely) dead; it would then be only r.master_stime
> which gets updated (see also Alejandro's reply), which surely wouldn't have
> required that call in the first place.

I'll follow Alejandro's suggestions