Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1554246 > unrolled thread

[PATCH 0/5] x86/microcode: More urgent fixes

Started byBorislav Petkov <bp@alien8.de>
First post2017-01-09 12:50 +0100
Last post2017-01-10 18:10 +0100
Articles 7 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/5] x86/microcode: More urgent fixes Borislav Petkov <bp@alien8.de> - 2017-01-09 12:50 +0100
    [PATCH 1/5] x86/CPU: Add native CPUID variants returning a single datum Borislav Petkov <bp@alien8.de> - 2017-01-09 12:50 +0100
      [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a  single datum tip-bot for Borislav Petkov <tipbot@zytor.com> - 2017-01-09 23:20 +0100
        Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum hpa@zytor.com - 2017-01-10 01:30 +0100
          Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a  single datum Borislav Petkov <bp@suse.de> - 2017-01-10 10:20 +0100
            Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum hpa@zytor.com - 2017-01-10 17:50 +0100
              Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a  single datum Borislav Petkov <bp@suse.de> - 2017-01-10 18:10 +0100

#1554246 — [PATCH 0/5] x86/microcode: More urgent fixes

FromBorislav Petkov <bp@alien8.de>
Date2017-01-09 12:50 +0100
Subject[PATCH 0/5] x86/microcode: More urgent fixes
Message-ID<sXGCC-3EW-3@gated-at.bofh.it>
From: Borislav Petkov <bp@suse.de>

Hi guys,

here are fixes for three more issues with the microcode loader. First
one is culminating in adding an intel_get_microcode_revision() helper
which does the proper steps to get the current microcode revision on
an Intel CPU and should be used everywhere instead of opencoding (and
forgetting) to do a CPUID(1).

The other two are fixes for 06b8534cb728 ("x86/microcode: Rework
microcode loading") which slipped through my testing.

All this is for 4.10 only as it fixes fallout from stuff which went in
this merge window.

Please apply,
thanks.

Borislav Petkov (3):
  x86/CPU: Add native CPUID variants returning a single datum
  x86/microcode: Use native CPUID to tickle out microcode revision
  x86/microcode/intel: Add a helper which gives the microcode revision

Junichi Nomura (2):
  x86/microcode/intel: Fix allocation size of struct ucode_patch
  x86/microcode/intel: Use correct buffer size for saving microcode data

 arch/x86/include/asm/microcode_intel.h | 15 ++++++++
 arch/x86/include/asm/processor.h       | 18 +++++++++
 arch/x86/kernel/cpu/intel.c            | 11 ++----
 arch/x86/kernel/cpu/microcode/intel.c  | 70 +++++++++-------------------------
 4 files changed, 53 insertions(+), 61 deletions(-)

-- 
2.11.0

[toc] | [next] | [standalone]


#1554248 — [PATCH 1/5] x86/CPU: Add native CPUID variants returning a single datum

FromBorislav Petkov <bp@alien8.de>
Date2017-01-09 12:50 +0100
Subject[PATCH 1/5] x86/CPU: Add native CPUID variants returning a single datum
Message-ID<sXGCD-3EW-21@gated-at.bofh.it>
In reply to#1554246
From: Borislav Petkov <bp@suse.de>

... similarly to the cpuid_<reg>() variants.

Signed-off-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/include/asm/processor.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index eaf100508c36..1be64da0384e 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -219,6 +219,24 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
 	    : "memory");
 }
 
+#define native_cpuid_reg(reg)					\
+static inline unsigned int native_cpuid_##reg(unsigned int op)	\
+{								\
+	unsigned int eax = op, ebx, ecx = 0, edx;		\
+								\
+	native_cpuid(&eax, &ebx, &ecx, &edx);			\
+								\
+	return reg;						\
+}
+
+/*
+ * Native CPUID functions returning a single datum.
+ */
+native_cpuid_reg(eax)
+native_cpuid_reg(ebx)
+native_cpuid_reg(ecx)
+native_cpuid_reg(edx)
+
 static inline void load_cr3(pgd_t *pgdir)
 {
 	write_cr3(__pa(pgdir));
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]


#1554760 — [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

Fromtip-bot for Borislav Petkov <tipbot@zytor.com>
Date2017-01-09 23:20 +0100
Subject[tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum
Message-ID<sXQsi-1ot-29@gated-at.bofh.it>
In reply to#1554248
Commit-ID:  5dedade6dfa243c130b85d1e4daba6f027805033
Gitweb:     http://git.kernel.org/tip/5dedade6dfa243c130b85d1e4daba6f027805033
Author:     Borislav Petkov <bp@suse.de>
AuthorDate: Mon, 9 Jan 2017 12:41:43 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Mon, 9 Jan 2017 23:11:13 +0100

x86/CPU: Add native CPUID variants returning a single datum

... similarly to the cpuid_<reg>() variants.

Signed-off-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/20170109114147.5082-2-bp@alien8.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---
 arch/x86/include/asm/processor.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index eaf1005..1be64da 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -219,6 +219,24 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
 	    : "memory");
 }
 
+#define native_cpuid_reg(reg)					\
+static inline unsigned int native_cpuid_##reg(unsigned int op)	\
+{								\
+	unsigned int eax = op, ebx, ecx = 0, edx;		\
+								\
+	native_cpuid(&eax, &ebx, &ecx, &edx);			\
+								\
+	return reg;						\
+}
+
+/*
+ * Native CPUID functions returning a single datum.
+ */
+native_cpuid_reg(eax)
+native_cpuid_reg(ebx)
+native_cpuid_reg(ecx)
+native_cpuid_reg(edx)
+
 static inline void load_cr3(pgd_t *pgdir)
 {
 	write_cr3(__pa(pgdir));

[toc] | [prev] | [next] | [standalone]


#1554824 — Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

Fromhpa@zytor.com
Date2017-01-10 01:30 +0100
SubjectRe: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum
Message-ID<sXSu5-2ym-13@gated-at.bofh.it>
In reply to#1554760
On January 9, 2017 2:16:07 PM PST, tip-bot for Borislav Petkov <tipbot@zytor.com> wrote:
>Commit-ID:  5dedade6dfa243c130b85d1e4daba6f027805033
>Gitweb:    
>http://git.kernel.org/tip/5dedade6dfa243c130b85d1e4daba6f027805033
>Author:     Borislav Petkov <bp@suse.de>
>AuthorDate: Mon, 9 Jan 2017 12:41:43 +0100
>Committer:  Thomas Gleixner <tglx@linutronix.de>
>CommitDate: Mon, 9 Jan 2017 23:11:13 +0100
>
>x86/CPU: Add native CPUID variants returning a single datum
>
>... similarly to the cpuid_<reg>() variants.
>
>Signed-off-by: Borislav Petkov <bp@suse.de>
>Link: http://lkml.kernel.org/r/20170109114147.5082-2-bp@alien8.de
>Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
>---
> arch/x86/include/asm/processor.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
>diff --git a/arch/x86/include/asm/processor.h
>b/arch/x86/include/asm/processor.h
>index eaf1005..1be64da 100644
>--- a/arch/x86/include/asm/processor.h
>+++ b/arch/x86/include/asm/processor.h
>@@ -219,6 +219,24 @@ static inline void native_cpuid(unsigned int *eax,
>unsigned int *ebx,
> 	    : "memory");
> }
> 
>+#define native_cpuid_reg(reg)					\
>+static inline unsigned int native_cpuid_##reg(unsigned int op)	\
>+{								\
>+	unsigned int eax = op, ebx, ecx = 0, edx;		\
>+								\
>+	native_cpuid(&eax, &ebx, &ecx, &edx);			\
>+								\
>+	return reg;						\
>+}
>+
>+/*
>+ * Native CPUID functions returning a single datum.
>+ */
>+native_cpuid_reg(eax)
>+native_cpuid_reg(ebx)
>+native_cpuid_reg(ecx)
>+native_cpuid_reg(edx)
>+
> static inline void load_cr3(pgd_t *pgdir)
> {
> 	write_cr3(__pa(pgdir));

Any reason to not make these interfaces (leaf, subleaf) from the start?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]


#1555065 — Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

FromBorislav Petkov <bp@suse.de>
Date2017-01-10 10:20 +0100
SubjectRe: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum
Message-ID<sY0L0-7Ue-7@gated-at.bofh.it>
In reply to#1554824
On Mon, Jan 09, 2017 at 04:19:29PM -0800, hpa@zytor.com wrote:
> Any reason to not make these interfaces (leaf, subleaf) from the start?

Two, actually:

1. I modelled them after the cpuid_<reg>(op) versions

2. I don't think we need the subleaf variant right now.

But, when we do, we can do that when we cross that bridge and add

native_cpuid_<reg>(leaf, subleaf)

which gets called by the native_cpuid_<reg>(leaf) variants.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]


#1555699 — Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

Fromhpa@zytor.com
Date2017-01-10 17:50 +0100
SubjectRe: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum
Message-ID<sY7Mt-3II-33@gated-at.bofh.it>
In reply to#1555065
On January 10, 2017 1:04:15 AM PST, Borislav Petkov <bp@suse.de> wrote:
>On Mon, Jan 09, 2017 at 04:19:29PM -0800, hpa@zytor.com wrote:
>> Any reason to not make these interfaces (leaf, subleaf) from the
>start?
>
>Two, actually:
>
>1. I modelled them after the cpuid_<reg>(op) versions

You are introducing a new API; makes more sense to do it right from the start.  The only reason not to have a subleaf for the non-native variants is that they may decay into a function call so there is an extra cost.

>2. I don't think we need the subleaf variant right now.

But at some point we will.  Just consider leaf 7.

>But, when we do, we can do that when we cross that bridge and add
>
>native_cpuid_<reg>(leaf, subleaf)
>
>which gets called by the native_cpuid_<reg>(leaf) variants.

C doesn't allow function name overloading ;) (Well, except the C11 type hacks; to the best of my knowledge that doesn't in any way support argument *count* overloading.)

This means that the naming will be awkward at best.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]


#1555712 — Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

FromBorislav Petkov <bp@suse.de>
Date2017-01-10 18:10 +0100
SubjectRe: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum
Message-ID<sY85Q-44s-21@gated-at.bofh.it>
In reply to#1555699
On Tue, Jan 10, 2017 at 08:40:39AM -0800, hpa@zytor.com wrote:
> You are introducing a new API; makes more sense to do it right from
> the start. The only reason not to have a subleaf for the non-native
> variants is that they may decay into a function call so there is an
> extra cost.

The "do it right" is what I'm not sure of. Do you see any use cases for
the subleaf != 0 *native* variant at all?

Most if not all users of native_cpuid() in the tree set ecx to 0.

> C doesn't allow function name overloading ;) (Well, except the C11
> type hacks; to the best of my knowledge that doesn't in any way
> support argument *count* overloading.)

Grr, I forgot to change the function name. I didn't mean that.

From looking at it again, what I mean would be ugly too :-)

I guess *if* the need arises - and again, I'm really sceptical about it
- we should simply add the respective native version of cpuid_count():

/* Some CPUID calls want 'count' to be placed in ecx */
static inline void native_cpuid_count(unsigned int op, int count,
	                               unsigned int *eax, unsigned int *ebx,
	                               unsigned int *ecx, unsigned int *edx)
{
        *eax = op;
        *ecx = count;
        native_cpuid(eax, ebx, ecx, edx);
}

Because this way you have both native and non-native versions nicely
comparable wrt arguments and retvals. And there won't be any confusion
wrt to "oh, the native version takes different args". This was my main
intent wrt the native_cpuid_<reg>() versions - to be consistent with the
cpuid_<reg>() ones.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web