From: Sohil Mehta <sohil.mehta@intel.com>
To: Dave Hansen <dave.hansen@intel.com>, <x86@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Tony Luck <tony.luck@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
"Kan Liang" <kan.liang@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, Andy Lutomirski <luto@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Fenghua Yu <fenghua.yu@intel.com>,
Jean Delvare <jdelvare@suse.com>,
Guenter Roeck <linux@roeck-us.net>,
Zhang Rui <rui.zhang@intel.com>,
<linux-perf-users@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
<linux-pm@vger.kernel.org>, <linux-hwmon@vger.kernel.org>
Subject: Re: [RFC PATCH 02/15] x86/apic: Fix smp init delay for extended Intel families
Date: Mon, 23 Dec 2024 13:55:07 -0800 [thread overview]
Message-ID: <74e6ec51-4475-40ec-9803-633378a5dcf2@intel.com> (raw)
In-Reply-To: <0875ab7b-0595-4195-924c-66da28074ef6@intel.com>
On 12/20/2024 3:20 PM, Dave Hansen wrote:
> On 12/20/24 13:36, Sohil Mehta wrote:
>> The MP specification version 1.4 references the i486 and early Pentium
>> processors in family 5.
>
> Can you please elaborate on how this reference is relevant to the patch
> at hand?
>
The comment above UDELAY_10MS_DEFAULT which references the MP
specification seems to be the basis of all the cpu_init_delay quirks.
I wanted to use that reference to justify that family 15 doesn't need
the 10 msec delay since it is not explicitly mentioned there. I realize
now that it's moot since the Pentium 4 wasn't released until 3 years
after it's publication.
I referred the latest MP initialization specification but that doesn't
say explicitly when the delay is needed vs not needed. However it does
say that later Family 6 models and Family 15 models have similar
initialization protocols.
"The selection of the BSP and APs is handled through a special system
bus cycle, without using BIPI and FIPI message arbitration (see Section
9.4.3, “MP Initialization Protocol Algorithm for MP Systems”). These
processor generations have CPUID signatures of family=0FH with
(model=0H, stepping>=0AH) or (model >0, all steppings); or family=06H,
extended_model=0, model>=0EH."
>> However, all processors starting with family 6 likely do not need the
>> 10 msec INIT delay. The omission of the Pentium 4s (family 15) seems
>> like an oversight in the original check.
>>
>> With some risk, choose a simpler check and extend the quirk to all
>> recent and upcoming Intel processors.
>
> I'm struggling to follow this a bit.
>
Because my interpretation of the code and the related comments is
opposite to yours. The usage of "quirk" in this context seems to be
inverted due to how this check has evolved over time.
> I think these are the facts that matter:
>
The code says this:
/* if modern processor, use no delay */
init_udelay = 0;
/* else, use legacy delay */
init_udelay = UDELAY_10MS_DEFAULT;
The legacy/default delay is 10 msec and then the quirk applies to the
modern processors to remove the delay. This is the comment above
UDELAY_10MS_DEFAULT:
* Modern processor families are quirked to remove the delay entirely.
> * init_udelay=0 means "no quirk"
> * Modern CPUs don't have the quirk
> * The current check says "only family 6 is modern"
> * Family 15 is _probably_ modern and just forgotten about
>
> And this is what you're doing in the end:
>
> Consider everything PPro and later to be modern, including all of
> families 6, 15 and the new 18/19 CPUs.
>
That's right. We consider these CPUs to be modern and do not apply the
10 msec delay but the usage of "quirk" is confusing here.
I'll clarify the changelog without using "quirk" to avoid confusion.
Am I interpreting this wrong?
next prev parent reply other threads:[~2024-12-23 21:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 21:36 [RFC PATCH 00/15] Prepare for new Intel family models Sohil Mehta
2024-12-20 21:36 ` [RFC PATCH 01/15] x86/apic: Fix 32-bit APIC initialization for extended Intel families Sohil Mehta
2024-12-20 23:13 ` Dave Hansen
2024-12-23 20:40 ` Sohil Mehta
2024-12-20 21:36 ` [RFC PATCH 02/15] x86/apic: Fix smp init delay " Sohil Mehta
2024-12-20 23:20 ` Dave Hansen
2024-12-23 21:55 ` Sohil Mehta [this message]
2024-12-20 21:36 ` [RFC PATCH 03/15] x86/cpu/intel: Fix init_intel() checks for extended family numbers Sohil Mehta
2024-12-20 23:27 ` Dave Hansen
2024-12-23 23:41 ` Sohil Mehta
2024-12-20 21:36 ` [RFC PATCH 04/15] cpufreq: Fix the efficient idle check for Intel extended families Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 05/15] hwmon: Fix Intel family checks to include extended family numbers Sohil Mehta
2024-12-21 17:27 ` Guenter Roeck
2024-12-23 18:13 ` Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 06/15] x86/microcode: Update the Intel processor flag scan check Sohil Mehta
2024-12-21 9:11 ` Borislav Petkov
2024-12-23 19:52 ` Sohil Mehta
2024-12-21 15:46 ` Dave Hansen
2024-12-20 21:37 ` [RFC PATCH 07/15] x86/mtrr: Modify a x86_model check to an Intel VFM check Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 08/15] x86/cpu/intel: Replace early family 6 checks with VFM ones Sohil Mehta
2024-12-21 10:35 ` David Laight
2024-12-21 15:57 ` Dave Hansen
2024-12-21 16:48 ` David Laight
2024-12-21 18:30 ` Dave Hansen
2024-12-23 20:13 ` Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 09/15] x86/cpu/intel: Replace family 15 " Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 10/15] x86/cpu/intel: Replace family 5 model " Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 11/15] x86/pat: Replace Intel " Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 12/15] x86/acpi/cstate: Improve Intel family model checks Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 13/15] x86/cpu/intel: Bound the non-architectural constant_tsc " Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 14/15] perf/x86: Simplify p6_pmu_init() Sohil Mehta
2024-12-20 21:37 ` [RFC PATCH 15/15] perf/x86/p4: Replace Pentium 4 model checks with VFM ones Sohil Mehta
2024-12-21 0:29 ` [RFC PATCH 00/15] Prepare for new Intel family models Andrew Cooper
2024-12-23 19:43 ` Sohil Mehta
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=74e6ec51-4475-40ec-9803-633378a5dcf2@intel.com \
--to=sohil.mehta@intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jdelvare@suse.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=viresh.kumar@linaro.org \
--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