* tip-bot for Borislav Petkov <[email protected]> wrote:
> Commit-ID: 132ec92f3f70fe365c1f4b8d46e66cf8a2a16880
> Gitweb: http://git.kernel.org/tip/132ec92f3f70fe365c1f4b8d46e66cf8a2a16880
> Author: Borislav Petkov <[email protected]>
> AuthorDate: Mon, 31 Aug 2009 09:50:09 +0200
> Committer: H. Peter Anvin <[email protected]>
> CommitDate: Mon, 31 Aug 2009 15:14:26 -0700
>
> x86, msr: Add rd/wrmsr interfaces with preset registers
module exports are missing:
ERROR: "native_wrmsr_safe_regs" [arch/x86/kernel/msr.ko] undefined!
ERROR: "native_rdmsr_safe_regs" [arch/x86/kernel/msr.ko] undefined!
config attached.
Ingo
On 09/04/2009 07:08 AM, Ingo Molnar wrote:
> * tip-bot for Borislav Petkov <[email protected]> wrote:
>
>> Commit-ID: 132ec92f3f70fe365c1f4b8d46e66cf8a2a16880
>> Gitweb: http://git.kernel.org/tip/132ec92f3f70fe365c1f4b8d46e66cf8a2a16880
>> Author: Borislav Petkov <[email protected]>
>> AuthorDate: Mon, 31 Aug 2009 09:50:09 +0200
>> Committer: H. Peter Anvin <[email protected]>
>> CommitDate: Mon, 31 Aug 2009 15:14:26 -0700
>>
>> x86, msr: Add rd/wrmsr interfaces with preset registers
>
> module exports are missing:
>
> ERROR: "native_wrmsr_safe_regs" [arch/x86/kernel/msr.ko] undefined!
> ERROR: "native_rdmsr_safe_regs" [arch/x86/kernel/msr.ko] undefined!
>
Uglier than that, msr-reg.o is defined as lib-y, which probably means
it's discarded completely if the kernel proper doesn't link it in.
It probably needs a new Kconfig variable or something... let me think
about it for a little bit.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Commit-ID: b19ae3999891cad21a3995c34d313dda5df014e2
Gitweb: http://git.kernel.org/tip/b19ae3999891cad21a3995c34d313dda5df014e2
Author: H. Peter Anvin <[email protected]>
AuthorDate: Fri, 4 Sep 2009 10:00:09 -0700
Committer: H. Peter Anvin <[email protected]>
CommitDate: Fri, 4 Sep 2009 10:00:09 -0700
x86, msr: change msr-reg.o to obj-y, and export its symbols
Change msr-reg.o to obj-y (it will be included in virtually every
kernel since it is used by the initialization code for AMD processors)
and add a separate C file to export its symbols to modules, so that
msr.ko can use them; on uniprocessors we bypass the helper functions
in msr.o and use the accessor functions directly via inlines.
Signed-off-by: H. Peter Anvin <[email protected]>
LKML-Reference: <[email protected]>
Cc: Borislav Petkov <[email protected]>
---
arch/x86/lib/Makefile | 3 ++-
arch/x86/lib/msr-reg-export.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index b59c064..9e60920 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -8,7 +8,8 @@ lib-y := delay.o
lib-y += thunk_$(BITS).o
lib-y += usercopy_$(BITS).o getuser.o putuser.o
lib-y += memcpy_$(BITS).o
-lib-y += msr-reg.o
+
+obj-y += msr-reg.o msr-reg-export.o
ifeq ($(CONFIG_X86_32),y)
obj-y += atomic64_32.o
diff --git a/arch/x86/lib/msr-reg-export.c b/arch/x86/lib/msr-reg-export.c
new file mode 100644
index 0000000..a311cc5
--- /dev/null
+++ b/arch/x86/lib/msr-reg-export.c
@@ -0,0 +1,5 @@
+#include <linux/module.h>
+#include <asm/msr.h>
+
+EXPORT_SYMBOL(native_rdmsr_safe_regs);
+EXPORT_SYMBOL(native_wrmsr_safe_regs);
On Fri, Sep 04, 2009 at 05:06:47PM +0000, tip-bot for H. Peter Anvin wrote:
> x86, msr: change msr-reg.o to obj-y, and export its symbols
>
> Change msr-reg.o to obj-y (it will be included in virtually every
> kernel since it is used by the initialization code for AMD processors)
Yeah, about that, I'm wondering whether a more fine grained
Kconfig suboptions would be appropriate here. Currently,
<arch/x86/kernel/cpu/{intel,amd}.c> are sprinkled with the
if (c->x86 == XX) { apply quirks }
thingies and we could put those into their own files which are
built/linked only when enabled. Before that, you would have chosen
the CPU vendor and the CPU family thus pulling only the related
quirks/fixes. Distros will of course need to enable all of them. Then,
all those different families quirks should be iterated over in a manner
similar to the initcall mechanism.
Anyways, just an idea - it could be dumb overengineering but on a
first glance it will organize/simplify the quirks code, reduce kernel
image proper, get rid of Kconfig options like CONFIG_X86_F00F_BUG,
vendor-specific cpuinfo_x86 members like fdiv_bug, f00f_bug, coma_bug,
and [add another good reason here :)].
Comments?
--
Regards/Gruss,
Boris.
On 09/05/2009 02:57 AM, Borislav Petkov wrote:
> On Fri, Sep 04, 2009 at 05:06:47PM +0000, tip-bot for H. Peter Anvin wrote:
>> x86, msr: change msr-reg.o to obj-y, and export its symbols
>>
>> Change msr-reg.o to obj-y (it will be included in virtually every
>> kernel since it is used by the initialization code for AMD processors)
>
> Yeah, about that, I'm wondering whether a more fine grained
> Kconfig suboptions would be appropriate here. Currently,
> <arch/x86/kernel/cpu/{intel,amd}.c> are sprinkled with the
>
> if (c->x86 == XX) { apply quirks }
>
> thingies and we could put those into their own files which are
> built/linked only when enabled. Before that, you would have chosen
> the CPU vendor and the CPU family thus pulling only the related
> quirks/fixes. Distros will of course need to enable all of them. Then,
> all those different families quirks should be iterated over in a manner
> similar to the initcall mechanism.
>
> Anyways, just an idea - it could be dumb overengineering but on a
> first glance it will organize/simplify the quirks code, reduce kernel
> image proper, get rid of Kconfig options like CONFIG_X86_F00F_BUG,
> vendor-specific cpuinfo_x86 members like fdiv_bug, f00f_bug, coma_bug,
> and [add another good reason here :)].
>
Ultimately the right thing to do would be to have the linker do these
kinds of things. This is easy enough when one deals with things that
have to be linked into the kernel binary, but the msr-reg issue is that
both the kernel proper and a module depend on the same thing... making
it a lib means the module doesn't get it.
All of this gets ugly, and I felt it wasn't enough code to worry about
in this case.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.