From: "Ahmed S. Darwish" <darwi@linutronix.de>
To: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Cooper <andrew.cooper3@citrix.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Sean Christopherson <seanjc@google.com>,
David Woodhouse <dwmw2@infradead.org>,
Peter Zijlstra <peterz@infradead.org>,
Christian Ludloff <ludloff@gmail.com>,
Sohil Mehta <sohil.mehta@intel.com>,
John Ogness <john.ogness@linutronix.de>,
x86@kernel.org, x86-cpuid@lists.linux.dev,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN
Date: Tue, 12 May 2026 09:12:25 +0200 [thread overview]
Message-ID: <agLS2Y7smYRHyiHf@lx-t490> (raw)
In-Reply-To: <20260511200032.GAagI1YMP51EzCo7dn@fat_crate.local>
Hi Boris,
On Mon, 11 May 2026, Borislav Petkov wrote:
>
> Except that those changes do not belong in this set. So I zapped them, see
> below.
>
Yeah, fair enough.
> Also, why are you doing this min_t thing?
>
> + rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
> + cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);
> + c->cpuid_level = l0->max_std_leaf;
>
The min_t() logic is meant to handle both max-CPUID-level increases and
decreases after the MSR write.
Assuming a machine with PSN and CPUID(0x3) as the max standard level:
c->cpuid_level == 3
-> MSR write, disable PSN
-> hardware: Max CPUID level becomes 2
Refresh CPUID(0x0)
l0->max_std_leaf == 2
cpuid_refresh_range(c, min(2, 3) + 1, CPUID_BASE_END)
Then, the CPUID parser will avoid touching CPUID(0x1) and CPUID(0x2) and
zero the table from CPUID(0x3) upwards.
Similarly, at patch (13/90), "x86/cpu/intel: Rescan CPUID table after leaf
unlock":
c->cpuid_level == 2
-> MSR write, disable BIOS limiting all leafs > CPUID(0x2)
-> hardware: Max CPUID level becomes 8
Refresh CPUID(0x0)
l0->max_std_leaf == 8
cpuid_refresh_range(c, min(2, 8) + 1, CPUID_BASE_END)
Then the CPUID parser will zero and refresh all leaves from CPUID(0x3)
upwards.
So the min_t()'s intent is just to be defensive against hardware surprises.
If you think this is superfulous, then ACK, removing it will not harm.
Thanks!
Ahmed
next prev parent reply other threads:[~2026-05-12 7:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260327021645.555257-1-darwi@linutronix.de>
[not found] ` <20260327152354.GBacahCioljpw5QqUc@fat_crate.local>
[not found] ` <acrBBFyU_vi4zFOx@lx-t490>
[not found] ` <20260330230836.GLacsCdDkVu0H3XU4l@fat_crate.local>
[not found] ` <adz3z_MaWJr_GOtc@lx-t490>
[not found] ` <ae-uw9836AJScRsq@lx-t490>
2026-05-05 13:33 ` [PATCH v6 00/90] x86: Introduce a centralized CPUID data model Borislav Petkov
2026-05-05 15:12 ` Borislav Petkov
2026-05-05 19:11 ` Christian Ludloff
2026-05-06 8:50 ` Borislav Petkov
2026-05-06 13:59 ` H. Peter Anvin
2026-05-06 14:58 ` Borislav Petkov
2026-05-06 18:13 ` Christian Ludloff
2026-05-06 21:57 ` Ahmed S. Darwish
2026-05-06 22:18 ` Borislav Petkov
2026-05-06 23:03 ` Christian Ludloff
2026-05-06 20:52 ` Ahmed S. Darwish
2026-05-07 10:17 ` Borislav Petkov
2026-05-07 20:02 ` Ahmed S. Darwish
[not found] ` <20260327021645.555257-11-darwi@linutronix.de>
2026-05-11 20:00 ` [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN Borislav Petkov
2026-05-12 7:12 ` Ahmed S. Darwish [this message]
2026-05-12 14:34 ` Borislav Petkov
2026-05-13 15:27 ` Borislav Petkov
2026-05-13 16:06 ` Ahmed S. Darwish
2026-05-13 16:51 ` Borislav Petkov
2026-05-13 17:09 ` Borislav Petkov
2026-05-13 17:21 ` H. Peter Anvin
2026-05-13 17:25 ` Ahmed S. Darwish
2026-05-13 17:38 ` Borislav Petkov
2026-05-13 15:57 ` Ahmed S. Darwish
2026-05-13 16:25 ` Ahmed S. Darwish
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=agLS2Y7smYRHyiHf@lx-t490 \
--to=darwi@linutronix.de \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ludloff@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=x86-cpuid@lists.linux.dev \
--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