[PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum

[PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum

[Evalds Iodzevics]

From: Borislav Petkov <bp@suse.de>

... 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 cac54e61c299..048942d53988 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -212,6 +212,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.17.4

[PATCH 2/2] Fixed broken microcode early loading on 32 bit platforms because it always jumps past cpuid in sync_core() as data structure boot_cpu_data are not populated so early in boot. This is for 4.4. Should be done for 4.9 too

[Evalds Iodzevics]

---
 arch/x86/include/asm/microcode_intel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/microcode_intel.h b/arch/x86/include/asm/microcode_intel.h
index 90343ba50485..92ce9c8a508b 100644
--- a/arch/x86/include/asm/microcode_intel.h
+++ b/arch/x86/include/asm/microcode_intel.h
@@ -60,7 +60,7 @@ static inline u32 intel_get_microcode_revision(void)
 	native_wrmsrl(MSR_IA32_UCODE_REV, 0);
 
 	/* As documented in the SDM: Do a CPUID 1 here */
-	sync_core();
+	native_cpuid_eax(1);
 
 	/* get the current revision from MSR 0x8B */
 	native_rdmsr(MSR_IA32_UCODE_REV, dummy, rev);
-- 
2.17.4

Re: [PATCH 2/2] Fixed broken microcode early loading on 32 bit platforms because it always jumps past cpuid in sync_core() as data structure boot_cpu_data are not populated so early in boot. This is for 4.4. Should be done for 4.9 too

[Greg KH]

On Sun, Apr 19, 2020 at 07:29:43PM +0300, Evalds Iodzevics wrote:
> ---
>  arch/x86/include/asm/microcode_intel.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Your subject line is really confused :(

Re: [PATCH 2/2] Fixed broken microcode early loading on 32 bit platforms because it always jumps past cpuid in sync_core() as data structure boot_cpu_data are not populated so early in boot. This is for 4.4. Should be done for 4.9 too

[Evalds Iodzevics]

Yeah, basically its a fix for early microcode load on x86 for 4.4 longterm
Just tried to say same problem exists on 4.9 too

On Sun, Apr 19, 2020 at 7:54 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Apr 19, 2020 at 07:29:43PM +0300, Evalds Iodzevics wrote:
> > ---
> >  arch/x86/include/asm/microcode_intel.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Your subject line is really confused :(
>

Re: [PATCH 2/2] Fixed broken microcode early loading on 32 bit platforms because it always jumps past cpuid in sync_core() as data structure boot_cpu_data are not populated so early in boot. This is for 4.4. Should be done for 4.9 too

[Greg KH]

On Mon, Apr 20, 2020 at 08:52:07AM +0300, Evalds Iodzevics wrote:
> Yeah, basically its a fix for early microcode load on x86 for 4.4 longterm
> Just tried to say same problem exists on 4.9 too

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum

[Greg KH]

On Sun, Apr 19, 2020 at 07:29:42PM +0300, Evalds Iodzevics wrote:
> From: Borislav Petkov <bp@suse.de>
> 
> ... 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(+)

Why are you resending patches from someone else?

Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum

[Evalds Iodzevics]

The second patch depends on this commit by Borislav so i included
this, probably I should have just mentioned it in my comment?

On Sun, Apr 19, 2020 at 7:54 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Apr 19, 2020 at 07:29:42PM +0300, Evalds Iodzevics wrote:
> > From: Borislav Petkov <bp@suse.de>
> >
> > ... 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(+)
>
> Why are you resending patches from someone else?

Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum

[Greg KH]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Mon, Apr 20, 2020 at 08:52:53AM +0300, Evalds Iodzevics wrote:
> The second patch depends on this commit by Borislav so i included
> this, probably I should have just mentioned it in my comment?

I really do not understand this sentence at all.  I have no context as
to what you are trying to do.

greg k-h