From: Borislav Petkov <bp@alien8.de>
To: Juergen Gross <jgross@suse.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v4 16/16] x86/mtrr: simplify mtrr_ops initialization
Date: Sun, 30 Oct 2022 17:39:14 +0100 [thread overview]
Message-ID: <Y16osqK3kbCz8Sf3@zn.tnic> (raw)
In-Reply-To: <dbd5861a-aa12-ea4f-c076-974613fba51c@suse.com>
On Sun, Oct 30, 2022 at 04:05:29PM +0100, Juergen Gross wrote:
> As the specific ops variables are available for X86_32 only, this
> would require to add an "#ifdef CONFIG_X86_32" around the code block
> doing the assignments. Otherwise the build would fail.
Well, it looks like my compiler is smart enough and eliminates all that
dead code, see diff below.
I've added the asm markers "#begin" and "#end" and the resulting asm
looks like this:
# arch/x86/kernel/cpu/mtrr/mtrr.c:666: asm volatile("#begin");
call __sanitizer_cov_trace_pc #
#APP
# 666 "arch/x86/kernel/cpu/mtrr/mtrr.c" 1
#begin
# 0 "" 2
# arch/x86/kernel/cpu/mtrr/mtrr.c:693: asm volatile("#end");
# 693 "arch/x86/kernel/cpu/mtrr/mtrr.c" 1
#end
# 0 "" 2
# arch/x86/kernel/cpu/mtrr/mtrr.c:630: phys_addr = 32;
#NO_APP
which basically says that all between line 666 and 693 has been
eliminated.
I have the suspicion, though, that clang might not be that smart.
Lemme test it a bit.
---
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
index 7ba68356c0ff..d499c83b2ad7 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.c
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
@@ -663,25 +663,26 @@ void __init mtrr_bp_init(void)
phys_addr = 32;
}
} else {
+ asm volatile("#begin");
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_AMD:
if (cpu_feature_enabled(X86_FEATURE_K6_MTRR)) {
/* Pre-Athlon (K6) AMD CPU MTRRs */
- mtrr_if = vendor_mtrr_ops(amd_mtrr_ops);
+ mtrr_if = &amd_mtrr_ops;
size_or_mask = SIZE_OR_MASK_BITS(32);
size_and_mask = 0;
}
break;
case X86_VENDOR_CENTAUR:
if (cpu_feature_enabled(X86_FEATURE_CENTAUR_MCR)) {
- mtrr_if = vendor_mtrr_ops(centaur_mtrr_ops);
+ mtrr_if = ¢aur_mtrr_ops;
size_or_mask = SIZE_OR_MASK_BITS(32);
size_and_mask = 0;
}
break;
case X86_VENDOR_CYRIX:
if (cpu_feature_enabled(X86_FEATURE_CYRIX_ARR)) {
- mtrr_if = vendor_mtrr_ops(cyrix_mtrr_ops);
+ mtrr_if = &cyrix_mtrr_ops;
size_or_mask = SIZE_OR_MASK_BITS(32);
size_and_mask = 0;
}
@@ -689,6 +690,7 @@ void __init mtrr_bp_init(void)
default:
break;
}
+ asm volatile("#end");
}
if (mtrr_if) {
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.h b/arch/x86/kernel/cpu/mtrr/mtrr.h
index 7a7387356192..02eb5871492d 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.h
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.h
@@ -68,11 +68,6 @@ void mtrr_wrmsr(unsigned, unsigned, unsigned);
extern const struct mtrr_ops amd_mtrr_ops;
extern const struct mtrr_ops cyrix_mtrr_ops;
extern const struct mtrr_ops centaur_mtrr_ops;
-#ifdef CONFIG_X86_64
-#define vendor_mtrr_ops(x) NULL
-#else
-#define vendor_mtrr_ops(x) &(x)
-#endif
extern int changed_by_mtrr_cleanup;
extern int mtrr_cleanup(unsigned address_bits);
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2022-10-30 16:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 8:10 [PATCH v4 00/16] x86: make pat and mtrr independent from each other Juergen Gross
2022-10-04 8:10 ` [PATCH v4 01/16] x86/mtrr: add comment for set_mtrr_state() serialization Juergen Gross
2022-10-04 8:10 ` [PATCH v4 02/16] x86/mtrr: remove unused cyrix_set_all() function Juergen Gross
2022-10-20 14:13 ` [tip: x86/cpu] x86/mtrr: Remove " tip-bot2 for Juergen Gross
2022-10-04 8:10 ` [PATCH v4 03/16] x86/mtrr: replace use_intel() with a local flag Juergen Gross
2022-10-21 17:19 ` Borislav Petkov
2022-10-21 18:05 ` Juergen Gross
2022-10-21 18:10 ` Borislav Petkov
2022-10-04 8:10 ` [PATCH v4 04/16] x86/mtrr: rename prepare_set() and post_set() Juergen Gross
2022-10-04 8:10 ` [PATCH v4 05/16] x86/mtrr: split MTRR specific handling from cache dis/enabling Juergen Gross
2022-10-26 9:24 ` Borislav Petkov
2022-10-26 11:42 ` Juergen Gross
2022-10-04 8:10 ` [PATCH v4 06/16] x86: move some code out of arch/x86/kernel/cpu/mtrr Juergen Gross
2022-10-04 8:10 ` [PATCH v4 07/16] x86/mtrr: split generic_set_all() Juergen Gross
2022-10-26 10:37 ` Borislav Petkov
2022-10-26 11:43 ` Juergen Gross
2022-10-26 12:10 ` Borislav Petkov
2022-10-04 8:10 ` [PATCH v4 08/16] x86/mtrr: remove set_all callback from struct mtrr_ops Juergen Gross
2022-10-27 9:18 ` Borislav Petkov
2022-10-04 8:10 ` [PATCH v4 09/16] x86/mtrr: simplify mtrr_bp_init() Juergen Gross
2022-10-27 9:32 ` Borislav Petkov
2022-10-04 8:10 ` [PATCH v4 10/16] x86/mtrr: get rid of mtrr_enabled bool Juergen Gross
2022-10-04 8:10 ` [PATCH v4 11/16] x86/mtrr: let cache_aps_delayed_init replace mtrr_aps_delayed_init Juergen Gross
2022-10-27 12:18 ` Borislav Petkov
2022-10-27 13:08 ` Juergen Gross
2022-10-04 8:10 ` [PATCH v4 12/16] x86/mtrr: add a stop_machine() handler calling only cache_cpu_init() Juergen Gross
2022-10-29 10:07 ` Borislav Petkov
2022-10-04 8:10 ` [PATCH v4 13/16] x86: decouple pat and mtrr handling Juergen Gross
2022-10-29 12:15 ` Borislav Petkov
2022-10-04 8:10 ` [PATCH v4 14/16] x86: switch cache_ap_init() to hotplug callback Juergen Gross
2022-10-04 8:10 ` [PATCH v4 15/16] x86: do MTRR/PAT setup on all secondary CPUs in parallel Juergen Gross
2022-10-04 8:10 ` [PATCH v4 16/16] x86/mtrr: simplify mtrr_ops initialization Juergen Gross
2022-10-30 12:06 ` Borislav Petkov
2022-10-30 15:05 ` Juergen Gross
2022-10-30 16:39 ` Borislav Petkov [this message]
2022-10-30 17:48 ` Borislav Petkov
2022-11-01 9:48 ` Juergen Gross
2022-11-01 10:02 ` Borislav Petkov
2022-10-19 7:18 ` [PATCH v4 00/16] x86: make pat and mtrr independent from each other Juergen Gross
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=Y16osqK3kbCz8Sf3@zn.tnic \
--to=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--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