All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
To: Stefano Stabellini <stefano.stabellini@amd.com>
Cc: <xen-devel@lists.xenproject.org>, <jbeulich@suse.com>,
	<andrew.cooper3@citrix.com>, <roger.pau@citrix.com>,
	<Xenia.Ragiadakou@amd.com>, <Jason.Andryuk@amd.com>
Subject: Re: [PATCH 1/2] xen/x86: don't send IPI to sync TSC when it is reliable
Date: Tue, 8 Jul 2025 19:53:02 +0200	[thread overview]
Message-ID: <DB6V62MVC3SM.2UN6E78FIRFMH@amd.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2507081016420.605088@ubuntu-linux-20-04-desktop>

On Tue Jul 8, 2025 at 7:40 PM CEST, Stefano Stabellini wrote:
> On Tue, 8 Jul 2025, Alejandro Vallejo wrote:
>> On Tue Jul 8, 2025 at 2:07 AM CEST, 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.
>> >
>> > Signed-off-by: Stefano Stabellini <stefano.stabellini@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 should check "(tsc_flags & TSC_RELIABLE_SOCKET)" as well. The TSCs might
>> still be unsynchronized across sockets.
>>
>> I'm still quite confused as to how Xen (mis)handles time, but wouldn't this need
>> to go inside the branch above? If the clocksource is not the TSC as well the TSC
>> can still drift with respect to the actual clocksource (PIT, HPET or ACPI timer).
>
> I can move it inside the previous if
>
>
>> If so, we could probably do an early return in the branch above ignoring the
>> conditions (they are required for picking the TSC clocksource already, including
>> synchronization across sockets).
>> 
>> Another matter is whether we could drop the "master_stime" write. Would we
>> care about it at all?
>
> I'll drop it.
>
> Is this what you had in mind?
>
>
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index 59129f419d..d72e640f72 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -2297,11 +2297,7 @@ static void cf_check time_calibration(void *unused)
>      };
>  
>      if ( clocksource_is_tsc() )
> -    {
> -        local_irq_disable();
> -        r.master_stime = read_platform_stime(&r.master_tsc_stamp);
> -        local_irq_enable();
> -    }
> +        return;
>  
>      cpumask_copy(&r.cpu_calibration_map, &cpu_online_map);
>  

Yes, I think that would do.

Cheers,
Alejandro


  reply	other threads:[~2025-07-08 17:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08  0:06 [PATCH 0/2] Xen real-time x86 Stefano Stabellini
2025-07-08  0:07 ` [PATCH 1/2] xen/x86: don't send IPI to sync TSC when it is reliable Stefano Stabellini
2025-07-08  9:54   ` Alejandro Vallejo
2025-07-08 17:40     ` Stefano Stabellini
2025-07-08 17:53       ` Alejandro Vallejo [this message]
2025-07-08 13:24   ` Jan Beulich
2025-07-08 17:40     ` Stefano Stabellini
2025-07-09  7:04       ` Jan Beulich
2025-07-08  0:07 ` [PATCH 2/2] xen/x86: introduce AMD_MCE_NONFATAL Stefano Stabellini
2025-07-08  3:23   ` Demi Marie Obenour
2025-07-08 10:25   ` Alejandro Vallejo
2025-07-08 13:28     ` Jan Beulich
2025-07-08 17:13       ` Stefano Stabellini
2025-07-08 10:11 ` [PATCH 0/2] Xen real-time x86 Roger Pau Monné
2025-07-08 13:31   ` Jan Beulich
2025-07-08 17:11     ` Stefano Stabellini
2025-07-09  5:37       ` Jan Beulich
2025-07-10  0:44         ` Stefano Stabellini
2025-07-10  7:02           ` Roger Pau Monné
2025-07-10  8:02             ` Jan Beulich
2025-07-10 21:39               ` Stefano Stabellini
2025-07-11  1:23                 ` Demi Marie Obenour
2025-07-09 14:10       ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB6V62MVC3SM.2UN6E78FIRFMH@amd.com \
    --to=alejandro.garciavallejo@amd.com \
    --cc=Jason.Andryuk@amd.com \
    --cc=Xenia.Ragiadakou@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=stefano.stabellini@amd.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.