From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
bp@alien8.de
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com,
dave.hansen@linux.intel.com, kernel@gpiccoli.net,
kernel-dev@igalia.com
Subject: Re: [PATCH] x86/tsc: Add debugfs entry to mark TSC as unstable after boot
Date: Sun, 23 Mar 2025 14:53:05 -0300 [thread overview]
Message-ID: <c9ce2eb1-bf90-3ce4-0adf-3f4e43f4a5bd@igalia.com> (raw)
In-Reply-To: <87iko213qo.ffs@tglx>
Thanks Thomas for your comprehensive response, quite enriching.
Some comments inline:
On 21/03/2025 18:19, Thomas Gleixner wrote:
> [...]
> The proposed implementation is just an ad hoc band aid as well. Why?
>
> 1) It has zero relation to the actual failure detection code paths.
>
> 2) It covers only a small part of the problem space. On all modern
> systems, which have TSC_ADJUST the clocksource watchdog is disabled
> and just asynchronously invoking TSC unstable is a hack which only
> tests the unstable logic.
But what about AMD systems? Even the modern ones apparently lack
TSC_ADJUST - or is it changing recently?
Checking TSC code, it is full of checks "if Intel" as well, like in
native calibration. Our issue is present on AMD and my impression is
that, in this respect, these systems are way more unstable (from TSC
perspective) than the ones having TSC_ADJUST.
>
> So I rather want to see a more complete solution, which
>
> 1) lets the clocksource watchdog logic fail the test
>
> 2) lets the TSC sync (including TSC_ADJUST) logic on CPU hotplug fail
>
> 3) tweaks the TSC_ADJUST register and validates that the detection and
> mitigation logic on systems w/o clocksource watchdog works
> correctly.
>
> Ideally that's a kunit test for CI integration plus a debugfs interface
> for developers, which comes with a related selftest.
>
This is a great suggestion. I'll try to come up with something in next
weeks (as time allows), I agree this area indeed seems to lack good/easy
testing.
Cheers,
Guilherme
next prev parent reply other threads:[~2025-03-23 17:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 13:27 Guilherme G. Piccoli
2025-03-17 14:35 ` Guilherme G. Piccoli
2025-03-17 18:42 ` H. Peter Anvin
2025-03-21 19:26 ` Guilherme G. Piccoli
2025-03-21 21:19 ` Thomas Gleixner
2025-03-23 17:53 ` Guilherme G. Piccoli [this message]
2025-03-23 18:14 ` Borislav Petkov
2025-03-23 19:21 ` Guilherme G. Piccoli
2025-03-23 19:51 ` Borislav Petkov
2025-03-23 19:59 ` Guilherme G. Piccoli
2025-03-17 14:40 ` Borislav Petkov
2025-03-17 15:03 ` Guilherme G. Piccoli
2025-03-17 15:14 ` Borislav Petkov
2025-03-17 15:24 ` Guilherme G. Piccoli
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=c9ce2eb1-bf90-3ce4-0adf-3f4e43f4a5bd@igalia.com \
--to=gpiccoli@igalia.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kernel-dev@igalia.com \
--cc=kernel@gpiccoli.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®