From: "Oleksii K." <oleksii.kurochko@gmail.com>
To: Jan Beulich <jbeulich@suse.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH for 4.19?] x86/Intel: unlock CPUID earlier for the BSP
Date: Thu, 13 Jun 2024 16:35:38 +0200 [thread overview]
Message-ID: <840d78dc1b27de61a0aa9931eb26ae896194fd0a.camel@gmail.com> (raw)
In-Reply-To: <82277592-ea96-47c8-a991-7afd97d7a7bc@suse.com>
On Thu, 2024-06-13 at 10:19 +0200, Jan Beulich wrote:
> Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
> this bit is set by the BIOS then CPUID evaluation does not work when
> data from any leaf greater than two is needed; early_cpu_init() in
> particular wants to collect leaf 7 data.
>
> Cure this by unlocking CPUID right before evaluating anything which
> depends on the maximum CPUID leaf being greater than two.
>
> Inspired by (and description cloned from) Linux commit 0c2f6d04619e
> ("x86/topology/intel: Unlock CPUID before evaluating anything").
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
~ Oleksii
> ---
> While I couldn't spot anything, it kind of feels as if I'm
> overlooking
> further places where we might be inspecting in particular leaf 7 yet
> earlier.
>
> No Fixes: tag(s), as imo it would be too many that would want
> enumerating.
>
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -336,7 +336,8 @@ void __init early_cpu_init(bool verbose)
>
> c->x86_vendor = x86_cpuid_lookup_vendor(ebx, ecx, edx);
> switch (c->x86_vendor) {
> - case X86_VENDOR_INTEL: actual_cpu = intel_cpu_dev;
> break;
> + case X86_VENDOR_INTEL: intel_unlock_cpuid_leaves(c);
> + actual_cpu = intel_cpu_dev;
> break;
> case X86_VENDOR_AMD: actual_cpu = amd_cpu_dev;
> break;
> case X86_VENDOR_CENTAUR: actual_cpu = centaur_cpu_dev;
> break;
> case X86_VENDOR_SHANGHAI: actual_cpu = shanghai_cpu_dev;
> break;
> --- a/xen/arch/x86/cpu/cpu.h
> +++ b/xen/arch/x86/cpu/cpu.h
> @@ -24,3 +24,5 @@ void amd_init_lfence(struct cpuinfo_x86
> void amd_init_ssbd(const struct cpuinfo_x86 *c);
> void amd_init_spectral_chicken(void);
> void detect_zen2_null_seg_behaviour(void);
> +
> +void intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c);
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -303,10 +303,24 @@ static void __init noinline intel_init_l
> ctxt_switch_masking = intel_ctxt_switch_masking;
> }
>
> -static void cf_check early_init_intel(struct cpuinfo_x86 *c)
> +/* Unmask CPUID levels if masked. */
> +void intel_unlock_cpuid_leaves(struct cpuinfo_x86 *c)
> {
> - u64 misc_enable, disable;
> + uint64_t misc_enable, disable;
> +
> + rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
> +
> + disable = misc_enable & MSR_IA32_MISC_ENABLE_LIMIT_CPUID;
> + if (disable) {
> + wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable &
> ~disable);
> + bootsym(trampoline_misc_enable_off) |= disable;
> + c->cpuid_level = cpuid_eax(0);
> + printk(KERN_INFO "revised cpuid level: %u\n", c-
> >cpuid_level);
> + }
> +}
>
> +static void cf_check early_init_intel(struct cpuinfo_x86 *c)
> +{
> /* Netburst reports 64 bytes clflush size, but does IO in
> 128 bytes */
> if (c->x86 == 15 && c->x86_cache_alignment == 64)
> c->x86_cache_alignment = 128;
> @@ -315,16 +329,7 @@ static void cf_check early_init_intel(st
> bootsym(trampoline_misc_enable_off) &
> MSR_IA32_MISC_ENABLE_XD_DISABLE)
> printk(KERN_INFO "re-enabled NX (Execute Disable)
> protection\n");
>
> - /* Unmask CPUID levels and NX if masked: */
> - rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
> -
> - disable = misc_enable & MSR_IA32_MISC_ENABLE_LIMIT_CPUID;
> - if (disable) {
> - wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable &
> ~disable);
> - bootsym(trampoline_misc_enable_off) |= disable;
> - printk(KERN_INFO "revised cpuid level: %d\n",
> - cpuid_eax(0));
> - }
> + intel_unlock_cpuid_leaves(c);
>
> /* CPUID workaround for Intel 0F33/0F34 CPU */
> if (boot_cpu_data.x86 == 0xF && boot_cpu_data.x86_model == 3
> &&
next prev parent reply other threads:[~2024-06-13 14:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 8:19 [PATCH for 4.19?] x86/Intel: unlock CPUID earlier for the BSP Jan Beulich
2024-06-13 14:35 ` Oleksii K. [this message]
2024-06-13 15:16 ` Roger Pau Monné
2024-06-13 15:53 ` Jan Beulich
2024-06-13 16:04 ` Roger Pau Monné
2024-06-13 16:12 ` Jan Beulich
2024-06-13 16:17 ` Andrew Cooper
2024-06-14 6:27 ` Jan Beulich
2024-06-14 10:14 ` Andrew Cooper
2024-06-14 11:12 ` Jan Beulich
2024-06-18 12:46 ` Andrew Cooper
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=840d78dc1b27de61a0aa9931eb26ae896194fd0a.camel@gmail.com \
--to=oleksii.kurochko@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.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.