[PATCH v4 1/2] lscpu-arm: Set the order to search the model name

[PATCH v4 1/2] lscpu-arm: Set the order to search the model name

[Masayoshi Mizuma]

From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>

After commit: 367c85c47 ("lscpu: use SMBIOS tables on ARM for lscpu"),
Model name for A64FX shows like as:

   Model name:       461F0010

That's because 367c85c47 changes to get the modelname from Processor
Version of SMBIOS.

The SMBIOS info would be great if the system is based on SBBR v1.2E and
BBR v1.0 because the specs require the Processor Version of SMBIOS
as "This field must provide a human readable description of the processor
part number".

However, it's not good for the systems aren't based on the specs,
like A64FX. Such systems need to have the model name to the hard
corded table.

Let's set the order; first, search the hard corded table, then SMBIOS.

Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
---
 sys-utils/lscpu-arm.c | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/sys-utils/lscpu-arm.c b/sys-utils/lscpu-arm.c
index 20c7291e5..3f258a710 100644
--- a/sys-utils/lscpu-arm.c
+++ b/sys-utils/lscpu-arm.c
@@ -288,6 +288,7 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc)
 	struct lscpu_dmi_header h;
 	int fd;
 	ssize_t rs;
+	int use_smbios = 0;
 
 	fd = open(_PATH_SYS_DMI_TYPE4, O_RDONLY);
 	if (fd < 0)
@@ -301,16 +302,21 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc)
 
 	to_dmi_header(&h, data);
 
-	str = dmi_string(&h, data[PROC_MFR_OFFSET]);
-	if (str) {
-		xstrncpy(buf, str, 127);
-		desc->vendor = xstrdup(buf);
+	if (!desc->modelname) {
+		str = dmi_string(&h, data[PROC_VERSION_OFFSET]);
+		if (str) {
+			xstrncpy(buf, str, 127);
+			desc->modelname = xstrdup(buf);
+			use_smbios = 1;
+		}
 	}
 
-	str = dmi_string(&h, data[PROC_VERSION_OFFSET]);
-	if (str) {
-		xstrncpy(buf, str, 127);
-		desc->modelname = xstrdup(buf);
+	if ((startswith(desc->vendor, "0x")) || use_smbios) {
+		str = dmi_string(&h, data[PROC_MFR_OFFSET]);
+		if (str) {
+			xstrncpy(buf, str, 127);
+			desc->vendor = xstrdup(buf);
+		}
 	}
 
 	return 0;
@@ -318,14 +324,11 @@ static int __arm_cpu_smbios(struct lscpu_desc *desc)
 
 void arm_cpu_decode(struct lscpu_desc *desc, struct lscpu_modifier *mod)
 {
-	int rc = -1;
+	__arm_cpu_decode(desc);
 
 	/* use SMBIOS Type 4 data if available,
 	 * else fall back to manual decoding using the tables above */
 	if (mod->system == SYSTEM_LIVE &&
 	    access(_PATH_SYS_DMI_TYPE4, R_OK) == 0)
-		rc = __arm_cpu_smbios(desc);
-
-	if (rc)
-		__arm_cpu_decode(desc);
+		__arm_cpu_smbios(desc);
 }
-- 
2.27.0

[PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Masayoshi Mizuma]

From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>

Remove hard corded model name of Cortex family and X-Gene so that
lscpu can show the model name using Processor Version of SMBIOS Type4.

Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
---
 sys-utils/lscpu-arm.c | 32 --------------------------------
 1 file changed, 32 deletions(-)

diff --git a/sys-utils/lscpu-arm.c b/sys-utils/lscpu-arm.c
index 3f258a710..6ece27349 100644
--- a/sys-utils/lscpu-arm.c
+++ b/sys-utils/lscpu-arm.c
@@ -53,37 +53,6 @@ static const struct id_part arm_part[] = {
     { 0xb36, "ARM1136" },
     { 0xb56, "ARM1156" },
     { 0xb76, "ARM1176" },
-    { 0xc05, "Cortex-A5" },
-    { 0xc07, "Cortex-A7" },
-    { 0xc08, "Cortex-A8" },
-    { 0xc09, "Cortex-A9" },
-    { 0xc0d, "Cortex-A17" },	/* Originally A12 */
-    { 0xc0f, "Cortex-A15" },
-    { 0xc0e, "Cortex-A17" },
-    { 0xc14, "Cortex-R4" },
-    { 0xc15, "Cortex-R5" },
-    { 0xc17, "Cortex-R7" },
-    { 0xc18, "Cortex-R8" },
-    { 0xc20, "Cortex-M0" },
-    { 0xc21, "Cortex-M1" },
-    { 0xc23, "Cortex-M3" },
-    { 0xc24, "Cortex-M4" },
-    { 0xc27, "Cortex-M7" },
-    { 0xc60, "Cortex-M0+" },
-    { 0xd01, "Cortex-A32" },
-    { 0xd03, "Cortex-A53" },
-    { 0xd04, "Cortex-A35" },
-    { 0xd05, "Cortex-A55" },
-    { 0xd07, "Cortex-A57" },
-    { 0xd08, "Cortex-A72" },
-    { 0xd09, "Cortex-A73" },
-    { 0xd0a, "Cortex-A75" },
-    { 0xd0b, "Cortex-A76" },
-    { 0xd0c, "Neoverse-N1" },
-    { 0xd13, "Cortex-R52" },
-    { 0xd20, "Cortex-M23" },
-    { 0xd21, "Cortex-M33" },
-    { 0xd4a, "Neoverse-E1" },
     { -1, "unknown" },
 };
 
@@ -110,7 +79,6 @@ static const struct id_part cavium_part[] = {
 };
 
 static const struct id_part apm_part[] = {
-    { 0x000, "X-Gene" },
     { -1, "unknown" },
 };
 
-- 
2.27.0

Re: [PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Karel Zak]

On Sun, Nov 08, 2020 at 10:04:03PM -0500, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> 
> Remove hard corded model name of Cortex family and X-Gene so that
> lscpu can show the model name using Processor Version of SMBIOS Type4.

Now I see on my system (Fedora) that:

 $ll /sys/firmware/dmi/entries/4-0/raw
 -r-------- 1 root root 0 Nov  9 17:19 /sys/firmware/dmi/entries/4-0/raw

it means it's not readable for non-root users. So, I guess the
hardcoded table can be still usable as a fallback solution if we want
to provide readable information for non-root.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Masayoshi Mizuma]

On Mon, Nov 09, 2020 at 05:23:31PM +0100, Karel Zak wrote:
> On Sun, Nov 08, 2020 at 10:04:03PM -0500, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> > 
> > Remove hard corded model name of Cortex family and X-Gene so that
> > lscpu can show the model name using Processor Version of SMBIOS Type4.
> 
> Now I see on my system (Fedora) that:
> 
>  $ll /sys/firmware/dmi/entries/4-0/raw
>  -r-------- 1 root root 0 Nov  9 17:19 /sys/firmware/dmi/entries/4-0/raw
> 
> it means it's not readable for non-root users. So, I guess the
> hardcoded table can be still usable as a fallback solution if we want
> to provide readable information for non-root.

Thanks, it's a really good point...
lscpu changes the Vendoer ID and Model name depends on the user privilege.
I think it may confuse users.

Why don't we remove Vendor ID and Model name when non-root runs lscpu?
Or add a message to get Vendor ID and Model name like as follows?

    $ lscpu
    ...
    Vendor ID:                       (Need to run as root to show)
    Model name:                      (Need to run as root to show)
    ...

Thanks,
Masa

Re: [PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Karel Zak]

On Mon, Nov 09, 2020 at 01:51:27PM -0500, Masayoshi Mizuma wrote:
> On Mon, Nov 09, 2020 at 05:23:31PM +0100, Karel Zak wrote:
> > On Sun, Nov 08, 2020 at 10:04:03PM -0500, Masayoshi Mizuma wrote:
> > > From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> > > 
> > > Remove hard corded model name of Cortex family and X-Gene so that
> > > lscpu can show the model name using Processor Version of SMBIOS Type4.
> > 
> > Now I see on my system (Fedora) that:
> > 
> >  $ll /sys/firmware/dmi/entries/4-0/raw
> >  -r-------- 1 root root 0 Nov  9 17:19 /sys/firmware/dmi/entries/4-0/raw
> > 
> > it means it's not readable for non-root users. So, I guess the
> > hardcoded table can be still usable as a fallback solution if we want
> > to provide readable information for non-root.
> 
> Thanks, it's a really good point...
> lscpu changes the Vendoer ID and Model name depends on the user privilege.
> I think it may confuse users.
> 
> Why don't we remove Vendor ID and Model name when non-root runs lscpu?
> Or add a message to get Vendor ID and Model name like as follows?
> 
>     $ lscpu
>     ...
>     Vendor ID:                       (Need to run as root to show)
>     Model name:                      (Need to run as root to show)
>     ...

It seems like user unfriendly solution, especially if it works in the
current versions.

And in some cases model name is important to get readable output. Now,
I'm working on new lscpu to get support for system with multiple CPU
models in one system. For example Cortex-A53 and Cortex-A72 together:

Architecture:          x86_64
  Byte Order:          Little Endian
CPU(s):                6
  On-line CPU(s) list: 0-5
Vendor ID:             ARM
Model name:            Cortex-A53
  Model:               4
  Thread(s) per core:  1
  Core(s) per socket:  4
  Socket(s):           1
  Stepping:            r0p4
  CPU max MHz:         1416.0000
  CPU min MHz:         408.0000
  BogoMIPS:            48.00
  Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
Model name:            Cortex-A72
  Model:               2
  Thread(s) per core:  1
  Core(s) per socket:  2
  Socket(s):           1
  Stepping:            r0p2
  CPU max MHz:         1800.0000
  CPU min MHz:         408.0000
  BogoMIPS:            48.00
  Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
NUMA:                  
  NUMA node(s):        1
  NUMA node0 CPU(s):   0-5
Vulnerabilities:       
  Itlb multihit:       Not affected
  L1tf:                Not affected
  Mds:                 Not affected
  Meltdown:            Not affected
  Spec store bypass:   Not affected
  Spectre v1:          Mitigation; __user pointer sanitization
  Spectre v2:          Mitigation; Branch predictor hardening
  Tsx async abort:     Not affected



This output is generated from /sys and /proc dump where we have 0x
values in cpuinfo.

I guess we can use firmware as primary a source if available,
otherwise static tables with names, or print raw values (e.g. 0xd08)
as the last possibility.

lscpu is not marketing tool, we can use technical information there,
it' better than hide anything ;-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Karel Zak]

On Tue, Nov 10, 2020 at 02:50:52PM -0600, Jeffrey Bastian wrote:
> On Tue, Nov 10, 2020 at 01:50:15PM -0500, Masayoshi Mizuma wrote:
> > On Tue, Nov 10, 2020 at 09:37:12AM +0100, Karel Zak wrote:
> > > On Mon, Nov 09, 2020 at 11:19:08PM -0600, Jeremy Linton wrote:
> > > > I don't agree with this, I think the hard coded table should be the first
> > > > authority on the manufacture/part number lists. That is because SMBIOS isn't
> > > > available on a fairly large number of arm systems, and on systems where it
> > > > does exist, it suffers from the same kinds of problems that exist on many
> > > > !arm machines. Its not particularly a reliable source of information.
> > > >
> > > > So, maybe if you have a situation where the SMBIOS information is more
> > > > correct than the hardcoded tables, maybe its a good idea to create a new
> > > > line?
> > > >
> > > >
> > > > Aka:
> > > >
> > > > Vendor Id: ARM
> > > > Model Name: Cortex-A57
> > > > BIOS Name: JoeSmithsCore
> > > 
> > > I like this idea.
> > 
> > Yeah, it's s great idea!
> > SMBIOS Type4 also has Vendor Id (Processor Manufacturer),
> > so the following is better?
> > 
> > Vendor Id: ARM
> > Model Name: Cortex-A57
> > BIOS Vendor Id: Foobar
> > BIOS Model Name: JoeSmithsCore
> > 
> > Jeff, does the above idea work for your case? X-Gene(eMAG) will be:
> > 
> > Vendor Id: APM
> > Model Name: X-Gene
> > BIOS Vendor Id: Ampere(TM)
> > BIOS Model Name: eMAG
> 
> 
> This is perfect.  I like the idea of showing both instead of preferring
> one over the other.

Sounds like a plan.

I'd like to merge my topic/lscpu branch to the master branch tomorrow (or
on Friday), the ideal solution will be to continue with this new code. 

 Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Jeffrey Bastian]

On Tue, Nov 10, 2020 at 01:50:15PM -0500, Masayoshi Mizuma wrote:
>On Tue, Nov 10, 2020 at 09:37:12AM +0100, Karel Zak wrote:
>> On Mon, Nov 09, 2020 at 11:19:08PM -0600, Jeremy Linton wrote:
>> > I don't agree with this, I think the hard coded table should be the first
>> > authority on the manufacture/part number lists. That is because SMBIOS isn't
>> > available on a fairly large number of arm systems, and on systems where it
>> > does exist, it suffers from the same kinds of problems that exist on many
>> > !arm machines. Its not particularly a reliable source of information.
>> >
>> > So, maybe if you have a situation where the SMBIOS information is more
>> > correct than the hardcoded tables, maybe its a good idea to create a new
>> > line?
>> >
>> >
>> > Aka:
>> >
>> > Vendor Id: ARM
>> > Model Name: Cortex-A57
>> > BIOS Name: JoeSmithsCore
>>
>> I like this idea.
>
>Yeah, it's s great idea!
>SMBIOS Type4 also has Vendor Id (Processor Manufacturer),
>so the following is better?
>
> Vendor Id: ARM
> Model Name: Cortex-A57
> BIOS Vendor Id: Foobar
> BIOS Model Name: JoeSmithsCore
>
>Jeff, does the above idea work for your case? X-Gene(eMAG) will be:
>
> Vendor Id: APM
> Model Name: X-Gene
> BIOS Vendor Id: Ampere(TM)
> BIOS Model Name: eMAG


This is perfect.  I like the idea of showing both instead of preferring
one over the other.

-- 
Jeff Bastian
Kernel QE - Hardware Enablement
Red Hat

Re: [PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Masayoshi Mizuma]

On Tue, Nov 10, 2020 at 09:37:12AM +0100, Karel Zak wrote:
> On Mon, Nov 09, 2020 at 11:19:08PM -0600, Jeremy Linton wrote:
> > I don't agree with this, I think the hard coded table should be the first
> > authority on the manufacture/part number lists. That is because SMBIOS isn't
> > available on a fairly large number of arm systems, and on systems where it
> > does exist, it suffers from the same kinds of problems that exist on many
> > !arm machines. Its not particularly a reliable source of information.
> > 
> > So, maybe if you have a situation where the SMBIOS information is more
> > correct than the hardcoded tables, maybe its a good idea to create a new
> > line?
> > 
> > 
> > Aka:
> > 
> > Vendor Id: ARM
> > Model Name: Cortex-A57
> > BIOS Name: JoeSmithsCore
> 
> I like this idea. 

Yeah, it's s great idea!
SMBIOS Type4 also has Vendor Id (Processor Manufacturer),
so the following is better?

 Vendor Id: ARM
 Model Name: Cortex-A57
 BIOS Vendor Id: Foobar
 BIOS Model Name: JoeSmithsCore

Jeff, does the above idea work for your case? X-Gene(eMAG) will be:

 Vendor Id: APM
 Model Name: X-Gene
 BIOS Vendor Id: Ampere(TM)
 BIOS Model Name: eMAG 

Thanks,
Masa

> 
> Note that for majority of our users know, use and expect names like
> Cortex-A57, but I have doubts about "JoeSmithsCore" :-)
> 
> > In the vast majority of cases I imagine the strings should match. The
> > problematic cases are LTS os's running on newer hardware. For that i'm
> > somewhat of the opinion the Model Name should remain "unknown" rather than
> > being silently updated. That is to avoid cases where the output from newer
> > lscpu's changes during an upgrade.
> > 
> > PS, Having this hardcoded table isn't optimal, but for now I think we are
> > stuck with it. Hopefully at some point we can work out a reliable way to
> > source the info. In the meantime, it looks like I need to submit some table
> > updates, since there are some newer arm models...
> 
> Yes.
> 
>     Karel
> 
> -- 
>  Karel Zak  <kzak@redhat.com>
>  http://karelzak.blogspot.com
> 

Re: [PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Karel Zak]

On Mon, Nov 09, 2020 at 11:19:08PM -0600, Jeremy Linton wrote:
> I don't agree with this, I think the hard coded table should be the first
> authority on the manufacture/part number lists. That is because SMBIOS isn't
> available on a fairly large number of arm systems, and on systems where it
> does exist, it suffers from the same kinds of problems that exist on many
> !arm machines. Its not particularly a reliable source of information.
> 
> So, maybe if you have a situation where the SMBIOS information is more
> correct than the hardcoded tables, maybe its a good idea to create a new
> line?
> 
> 
> Aka:
> 
> Vendor Id: ARM
> Model Name: Cortex-A57
> BIOS Name: JoeSmithsCore

I like this idea. 

Note that for majority of our users know, use and expect names like
Cortex-A57, but I have doubts about "JoeSmithsCore" :-)

> In the vast majority of cases I imagine the strings should match. The
> problematic cases are LTS os's running on newer hardware. For that i'm
> somewhat of the opinion the Model Name should remain "unknown" rather than
> being silently updated. That is to avoid cases where the output from newer
> lscpu's changes during an upgrade.
> 
> PS, Having this hardcoded table isn't optimal, but for now I think we are
> stuck with it. Hopefully at some point we can work out a reliable way to
> source the info. In the meantime, it looks like I need to submit some table
> updates, since there are some newer arm models...

Yes.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

[PATCH v4 2/2] lscpu-arm: Remove hard corded model name of Cortex family and X-Gene

[Jeremy Linton]

Hi,

(sorry about the threading problem, I wasn't a linux-util subscriber)

It appears you are removing much of the hard coded cpu part number lists.

I don't agree with this, I think the hard coded table should be the 
first authority on the manufacture/part number lists. That is because 
SMBIOS isn't available on a fairly large number of arm systems, and on 
systems where it does exist, it suffers from the same kinds of problems 
that exist on many !arm machines. Its not particularly a reliable source 
of information.

So, maybe if you have a situation where the SMBIOS information is more 
correct than the hardcoded tables, maybe its a good idea to create a new 
line?


Aka:

Vendor Id: ARM
Model Name: Cortex-A57
BIOS Name: JoeSmithsCore


In the vast majority of cases I imagine the strings should match. The 
problematic cases are LTS os's running on newer hardware. For that i'm 
somewhat of the opinion the Model Name should remain "unknown" rather 
than being silently updated. That is to avoid cases where the output 
from newer lscpu's changes during an upgrade.

PS, Having this hardcoded table isn't optimal, but for now I think we 
are stuck with it. Hopefully at some point we can work out a reliable 
way to source the info. In the meantime, it looks like I need to submit 
some table updates, since there are some newer arm models...