* [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
@ 2020-04-19 16:29 Evalds Iodzevics
2020-04-19 16:29 ` [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
2020-04-19 16:54 ` [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Greg KH
0 siblings, 2 replies; 8+ messages in thread
From: Evalds Iodzevics @ 2020-04-19 16:29 UTC (permalink / raw)
To: linux-kernel; +Cc: gregkh, Borislav Petkov, Thomas Gleixner
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
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [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
2020-04-19 16:29 [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Evalds Iodzevics
@ 2020-04-19 16:29 ` Evalds Iodzevics
2020-04-19 16:54 ` Greg KH
2020-04-19 16:54 ` [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Greg KH
1 sibling, 1 reply; 8+ messages in thread
From: Evalds Iodzevics @ 2020-04-19 16:29 UTC (permalink / raw)
To: linux-kernel; +Cc: gregkh, 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
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
2020-04-19 16:29 [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Evalds Iodzevics
2020-04-19 16:29 ` [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
@ 2020-04-19 16:54 ` Greg KH
2020-04-20 5:52 ` Evalds Iodzevics
1 sibling, 1 reply; 8+ messages in thread
From: Greg KH @ 2020-04-19 16:54 UTC (permalink / raw)
To: Evalds Iodzevics; +Cc: linux-kernel, Borislav Petkov, Thomas Gleixner
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* 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
2020-04-19 16:29 ` [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
@ 2020-04-19 16:54 ` Greg KH
2020-04-20 5:52 ` Evalds Iodzevics
0 siblings, 1 reply; 8+ messages in thread
From: Greg KH @ 2020-04-19 16:54 UTC (permalink / raw)
To: Evalds Iodzevics; +Cc: linux-kernel
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 :(
^ permalink raw reply [flat|nested] 8+ messages in thread
* 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
2020-04-19 16:54 ` Greg KH
@ 2020-04-20 5:52 ` Evalds Iodzevics
2020-04-20 6:07 ` Greg KH
0 siblings, 1 reply; 8+ messages in thread
From: Evalds Iodzevics @ 2020-04-20 5:52 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
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 :(
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
2020-04-19 16:54 ` [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Greg KH
@ 2020-04-20 5:52 ` Evalds Iodzevics
2020-04-20 6:07 ` Greg KH
0 siblings, 1 reply; 8+ messages in thread
From: Evalds Iodzevics @ 2020-04-20 5:52 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, Borislav Petkov, Thomas Gleixner
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
2020-04-20 5:52 ` Evalds Iodzevics
@ 2020-04-20 6:07 ` Greg KH
0 siblings, 0 replies; 8+ messages in thread
From: Greg KH @ 2020-04-20 6:07 UTC (permalink / raw)
To: Evalds Iodzevics; +Cc: linux-kernel, Borislav Petkov, Thomas Gleixner
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* 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
2020-04-20 5:52 ` Evalds Iodzevics
@ 2020-04-20 6:07 ` Greg KH
0 siblings, 0 replies; 8+ messages in thread
From: Greg KH @ 2020-04-20 6:07 UTC (permalink / raw)
To: Evalds Iodzevics; +Cc: linux-kernel
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>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-04-20 6:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-19 16:29 [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Evalds Iodzevics
2020-04-19 16:29 ` [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
2020-04-19 16:54 ` Greg KH
2020-04-20 5:52 ` Evalds Iodzevics
2020-04-20 6:07 ` Greg KH
2020-04-19 16:54 ` [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Greg KH
2020-04-20 5:52 ` Evalds Iodzevics
2020-04-20 6:07 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).