linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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; 15+ 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] 15+ 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; 15+ 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] 15+ 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; 15+ 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] 15+ 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; 15+ 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] 15+ 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; 15+ 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] 15+ 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; 15+ 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] 15+ 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; 15+ 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] 15+ 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; 15+ 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] 15+ messages in thread

* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
  2017-01-03 18:35             ` Andy Lutomirski
@ 2017-01-03 19:48               ` Borislav Petkov
  0 siblings, 0 replies; 15+ messages in thread
From: Borislav Petkov @ 2017-01-03 19:48 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: Junichi Nomura, x86, linux-kernel, tglx, mingo, hpa

On Tue, Jan 03, 2017 at 10:35:15AM -0800, Andy Lutomirski wrote:
> That's why I didn't type "volatile". :)

I think you lost me: the version I'm proposing is with a retval you can
choose to ignore or not and it works either way due to the volatile...

Hmmm?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
  2016-12-31 11:09           ` Borislav Petkov
@ 2017-01-03 18:35             ` Andy Lutomirski
  2017-01-03 19:48               ` Borislav Petkov
  0 siblings, 1 reply; 15+ messages in thread
From: Andy Lutomirski @ 2017-01-03 18:35 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: Junichi Nomura, x86, linux-kernel, tglx, mingo, hpa

On Sat, Dec 31, 2016 at 3:09 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Fri, Dec 30, 2016 at 06:13:24PM -0800, Andy Lutomirski wrote:
>> Now you call it and ignore the return value and the compiler optimizes
>> it out :)
>
> Does it, really?
>
> It is an inlined asm volatile. I checked all call sites and the CPUID
> call is there. gcc 6 simply issues the CPUID and then later code
> overwrites rAX. I.e., it looks ok to me.
>
> Or what example scenario do you have in mind?

That's why I didn't type "volatile". :)

>
>> Also, someone reading the code might scratch their head and
>> wonder why you picked eax and not ebx, ecx, or edx.
>
> We have comments for her/him :-)

Okay.  Anyway, this particular nit is minor and I'll shut up.

>
> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --



-- 
Andy Lutomirski
AMA Capital Management, LLC

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
  2016-12-31  2:13         ` Andy Lutomirski
@ 2016-12-31 11:09           ` Borislav Petkov
  2017-01-03 18:35             ` Andy Lutomirski
  0 siblings, 1 reply; 15+ messages in thread
From: Borislav Petkov @ 2016-12-31 11:09 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: Junichi Nomura, x86, linux-kernel, tglx, mingo, hpa

On Fri, Dec 30, 2016 at 06:13:24PM -0800, Andy Lutomirski wrote:
> Now you call it and ignore the return value and the compiler optimizes
> it out :)

Does it, really?

It is an inlined asm volatile. I checked all call sites and the CPUID
call is there. gcc 6 simply issues the CPUID and then later code
overwrites rAX. I.e., it looks ok to me.

Or what example scenario do you have in mind?

> Also, someone reading the code might scratch their head and
> wonder why you picked eax and not ebx, ecx, or edx.

We have comments for her/him :-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
  2016-12-29  9:30       ` Borislav Petkov
@ 2016-12-31  2:13         ` Andy Lutomirski
  2016-12-31 11:09           ` Borislav Petkov
  0 siblings, 1 reply; 15+ messages in thread
From: Andy Lutomirski @ 2016-12-31  2:13 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: Junichi Nomura, x86, linux-kernel, tglx, mingo, hpa

On Thu, Dec 29, 2016 at 1:30 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Dec 28, 2016 at 10:11:22AM -0800, Andy Lutomirski wrote:
>> On a very quick read, it looks like none of your new call sites
>> actually use the return value at all.  Since you also appear to be
>> consolidating them all, would it make sense to just open-code the
>> single (?) remaining user?
>
> I've got stuff coming up which will use the retval but it is not fully
> cooked yet. And also, we want to have generic helpers so that people do
> not reimplement them left and right.

Okay, but I still think that a variant that says "do cpuid and ignore
the return value" would make sense.  Imagine a very clever
implementation of native_cpuid_eax like:

asm ("cpuid" : "=a" (eax) : ...);
return eax;

Now you call it and ignore the return value and the compiler optimizes
it out :)  Also, someone reading the code might scratch their head and
wonder why you picked eax and not ebx, ecx, or edx.

--Andy

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
  2016-12-28 18:11     ` Andy Lutomirski
@ 2016-12-29  9:30       ` Borislav Petkov
  2016-12-31  2:13         ` Andy Lutomirski
  0 siblings, 1 reply; 15+ messages in thread
From: Borislav Petkov @ 2016-12-29  9:30 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: Junichi Nomura, x86, linux-kernel, tglx, mingo, hpa

On Wed, Dec 28, 2016 at 10:11:22AM -0800, Andy Lutomirski wrote:
> On a very quick read, it looks like none of your new call sites
> actually use the return value at all.  Since you also appear to be
> consolidating them all, would it make sense to just open-code the
> single (?) remaining user?

I've got stuff coming up which will use the retval but it is not fully
cooked yet. And also, we want to have generic helpers so that people do
not reimplement them left and right.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
  2016-12-28 11:20   ` [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Borislav Petkov
@ 2016-12-28 18:11     ` Andy Lutomirski
  2016-12-29  9:30       ` Borislav Petkov
  0 siblings, 1 reply; 15+ messages in thread
From: Andy Lutomirski @ 2016-12-28 18:11 UTC (permalink / raw)
  To: Borislav Petkov; +Cc: Junichi Nomura, x86, linux-kernel, tglx, mingo, hpa

On Wed, Dec 28, 2016 at 3:20 AM, Borislav Petkov <bp@alien8.de> wrote:
> From: Borislav Petkov <bp@suse.de>
>
> ... similar 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..27ae83fc37de 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;             \

The parens around (op) shouldn't be needed.

> +                                                               \
> +       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)
> +

On a very quick read, it looks like none of your new call sites
actually use the return value at all.  Since you also appear to be
consolidating them all, would it make sense to just open-code the
single (?) remaining user?

--Andy

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum
  2016-12-28 11:18 ` Borislav Petkov
@ 2016-12-28 11:20   ` Borislav Petkov
  2016-12-28 18:11     ` Andy Lutomirski
  0 siblings, 1 reply; 15+ messages in thread
From: Borislav Petkov @ 2016-12-28 11:20 UTC (permalink / raw)
  To: Junichi Nomura; +Cc: x86, linux-kernel, Andy Lutomirski, tglx, mingo, hpa

From: Borislav Petkov <bp@suse.de>

... similar 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..27ae83fc37de 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.8.4

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

^ permalink raw reply related	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2020-04-20  6:07 UTC | newest]

Thread overview: 15+ 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
  -- strict thread matches above, loose matches on Subject: below --
2016-12-28  4:39 [PATCH] x86: Fix Intel microcode revision detection Junichi Nomura
2016-12-28 11:18 ` Borislav Petkov
2016-12-28 11:20   ` [PATCH 1/2] x86/CPU: Add native CPUID variants returning a single datum Borislav Petkov
2016-12-28 18:11     ` Andy Lutomirski
2016-12-29  9:30       ` Borislav Petkov
2016-12-31  2:13         ` Andy Lutomirski
2016-12-31 11:09           ` Borislav Petkov
2017-01-03 18:35             ` Andy Lutomirski
2017-01-03 19:48               ` Borislav Petkov

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).