From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
bp@alien8.de, rafael@kernel.org, lenb@kernel.org,
dave.jiang@intel.com, irenic.rajneesh@gmail.com,
david.e.box@intel.com
Subject: Re: [PATCH 04/11] x86/acpi: Check MWAIT feature instead of CPUID level
Date: Thu, 21 Nov 2024 07:33:51 -0800 [thread overview]
Message-ID: <Zz9S352550TZSKBQ@google.com> (raw)
In-Reply-To: <20241120195332.929A7C44@davehans-spike.ostc.intel.com>
On Wed, Nov 20, 2024, Dave Hansen wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> I think this code is possibly buggy. The CPU could have a high
> c->cpuid_level and not support MWAIT at all.
Reading CPUID.0x5 is totally fine in that case though. Wasteful and pointless,
but functionally ok. If the CPU provides non-zero values when MWAIT is unsupported,
then that's a broken CPU.
> It is much more clear to
> just check for MWAIT support directly. Also, because of the CPU level
> dependency code, any CPU that has X86_FEATURE_MWAIT also has a
> high-enough CPUID level.
No? The MWAIT feature flag is in leaf 1. 1 < 5, and I don't see any cpuid_level
magic that would force it beyond '5'.
Why not check both?
> Check X86_FEATURE_MWAIT instead of the CPUID level.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> ---
>
> b/arch/x86/kernel/acpi/cstate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN arch/x86/kernel/acpi/cstate.c~mwait-leaf-checks-3 arch/x86/kernel/acpi/cstate.c
> --- a/arch/x86/kernel/acpi/cstate.c~mwait-leaf-checks-3 2024-11-20 11:44:17.225650902 -0800
> +++ b/arch/x86/kernel/acpi/cstate.c 2024-11-20 11:44:17.225650902 -0800
> @@ -173,7 +173,7 @@ int acpi_processor_ffh_cstate_probe(unsi
> struct cpuinfo_x86 *c = &cpu_data(cpu);
> long retval;
>
> - if (!cpu_cstate_entry || c->cpuid_level < CPUID_MWAIT_LEAF)
> + if (!cpu_cstate_entry || cpu_has(c, X86_FEATURE_MWAIT))
Someone didn't test this :-)
> return -1;
>
> if (reg->bit_offset != NATIVE_CSTATE_BEYOND_HALT)
> _
next prev parent reply other threads:[~2024-11-21 15:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 19:53 [PATCH 00/11] x86/cpu: Centralize and standardize CPUID leaf naming Dave Hansen
2024-11-20 19:53 ` [PATCH 01/11] x86/cpu: Move MWAIT leaf definition to common header Dave Hansen
2024-11-26 3:20 ` Zhao Liu
2024-11-20 19:53 ` [PATCH 02/11] x86/cpu: Use MWAIT leaf definition Dave Hansen
2024-11-26 3:24 ` Zhao Liu
2024-11-20 19:53 ` [PATCH 03/11] x86/cpu: Remove unnecessary MwAIT leaf checks Dave Hansen
2024-11-20 19:53 ` [PATCH 04/11] x86/acpi: Check MWAIT feature instead of CPUID level Dave Hansen
2024-11-21 15:33 ` Sean Christopherson [this message]
2024-11-21 21:46 ` Dave Hansen
2024-11-20 19:53 ` [PATCH 05/11] x86/cpu: Refresh DCA leaf reading code Dave Hansen
2024-11-26 4:11 ` Zhao Liu
2024-11-26 3:55 ` Dave Hansen
2024-11-20 19:53 ` [PATCH 06/11] x86/cpu: Move TSC CPUID leaf definition Dave Hansen
2024-11-26 4:23 ` Zhao Liu
2024-11-20 19:53 ` [PATCH 07/11] x86/tsc: Move away from TSC leaf magic numbers Dave Hansen
2024-11-20 19:53 ` [PATCH 08/11] x86/tsc: Remove CPUID "frequency" " Dave Hansen
2024-11-26 4:37 ` Zhao Liu
2024-11-20 19:53 ` [PATCH 09/11] x86/fpu: Move CPUID leaf definitions to common code Dave Hansen
2024-11-26 4:43 ` Zhao Liu
2024-11-20 19:53 ` [PATCH 10/11] x86/fpu: Remove unnecessary CPUID level check Dave Hansen
2024-11-21 15:45 ` Sean Christopherson
2024-11-22 17:46 ` Dave Hansen
2024-11-20 19:53 ` [PATCH 11/11] x86/cpu: Make all all CPUID leaf names consistent Dave Hansen
2024-11-20 20:23 ` Dave Jiang
-- strict thread matches above, loose matches on Subject: below --
2024-10-30 21:33 [PATCH 00/11] x86/cpu: Centralize and standardize CPUID leaf naming Dave Hansen
2024-10-30 21:33 ` [PATCH 04/11] x86/acpi: Check MWAIT feature instead of CPUID level Dave Hansen
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=Zz9S352550TZSKBQ@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=david.e.box@intel.com \
--cc=irenic.rajneesh@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--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 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.