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.stabell...@amd.com> > > --- > > 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
