[PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[Thomas Renninger]

I picked up Felix Schnizlein's work from 2017.

It was already reviewed by Greg-KH at this time and even
pushed into linux-next tree, when it came out that the mails
never reached lkml, even the list was added to CC.

ARM people then correctly complained that this needs more review
by ARCH people. It got reverted, Felix had no time anymore and this
nice patcheset was hanging around nowhere...


Changes (by trenn) since v4:
- Do not separate bug and flag list via comma, but by space
- Adjust renamed cpu_data(c).x86_mask to cpu_data(c).x86_stepping
  due to commit b399151cb48db30ad1e0
- Introduce
  config CPUINFO_SYSFS
  and use config HAVE_CPUINFO_SYSFS as a pre-set helper only
- Set CPUINFO_SYSFS
  def_bool y

=============================================

Tested on x86_64 and aarch64 (see below).

Tested on x86_64 (virtual machine):

------------------------------------------------------------

/sys/devices/system/cpu/cpu1/info/:[0]# ls
bogomips  bugs  cpu_family  flags  model  model_name  stepping  vendor_id

for file in *;do echo $file; cat $file;echo;done
bogomips
5187.72

bugs
cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs 
itlb_multihit

cpu_family
6

flags
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc 
rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid 
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand 
hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip

model
60

model_name
Intel Core Processor (Haswell, no TSX, IBRS)

stepping
1

vendor_id
GenuineIntel

=============================================

Tested on aarch64:

/sys/devices/system/cpu/cpu1/info/:[0]# ls
architecture  bogomips  flags  implementer  part  revision  variant

------------------------------------------------------------

for file in *;do echo $file; cat $file;echo;done
architecture
8

bogomips
40.00

flags
fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm

implementer
0x51

part
0xc00

revision
1

variant
0x0


Felix Schnizlein (3):
  cpuinfo: add sysfs based arch independent cpuinfo framework
  x86 cpuinfo: implement sysfs nodes for x86
  arm64 cpuinfo: implement sysfs nodes for arm64

 Documentation/ABI/testing/sysfs-devices-system-cpu | 52 ++++++++++++
 arch/Kconfig                                       | 11 +++
 arch/arm64/Kconfig                                 |  1 +
 arch/arm64/kernel/cpuinfo.c                        | 55 ++++++++++++
 arch/x86/Kconfig                                   |  1 +
 arch/x86/kernel/Makefile                           |  2 +
 arch/x86/kernel/cpuinfo.c                          | 99 ++++++++++++++++++++++
 drivers/base/Makefile                              |  1 +
 drivers/base/cpuinfo.c                             | 48 +++++++++++
 include/linux/cpuhotplug.h                         |  1 +
 include/linux/cpuinfo.h                            | 43 ++++++++++
 11 files changed, 314 insertions(+)
 create mode 100644 arch/x86/kernel/cpuinfo.c
 create mode 100644 drivers/base/cpuinfo.c
 create mode 100644 include/linux/cpuinfo.h

-- 
2.16.4

[PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[Thomas Renninger]

I picked up Felix Schnizlein's work from 2017.

It was already reviewed by Greg-KH at this time and even
pushed into linux-next tree, when it came out that the mails
never reached lkml, even the list was added to CC.

ARM people then correctly complained that this needs more review
by ARCH people. It got reverted, Felix had no time anymore and this
nice patcheset was hanging around nowhere...


Changes (by trenn) since v4:
- Do not separate bug and flag list via comma, but by space
- Adjust renamed cpu_data(c).x86_mask to cpu_data(c).x86_stepping
  due to commit b399151cb48db30ad1e0
- Introduce
  config CPUINFO_SYSFS
  and use config HAVE_CPUINFO_SYSFS as a pre-set helper only
- Set CPUINFO_SYSFS
  def_bool y

=============================================

Tested on x86_64 and aarch64 (see below).

Tested on x86_64 (virtual machine):

------------------------------------------------------------

/sys/devices/system/cpu/cpu1/info/:[0]# ls
bogomips  bugs  cpu_family  flags  model  model_name  stepping  vendor_id

for file in *;do echo $file; cat $file;echo;done
bogomips
5187.72

bugs
cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs 
itlb_multihit

cpu_family
6

flags
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc 
rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid 
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand 
hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase 
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip

model
60

model_name
Intel Core Processor (Haswell, no TSX, IBRS)

stepping
1

vendor_id
GenuineIntel

=============================================

Tested on aarch64:

/sys/devices/system/cpu/cpu1/info/:[0]# ls
architecture  bogomips  flags  implementer  part  revision  variant

------------------------------------------------------------

for file in *;do echo $file; cat $file;echo;done
architecture
8

bogomips
40.00

flags
fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm

implementer
0x51

part
0xc00

revision
1

variant
0x0


Felix Schnizlein (3):
  cpuinfo: add sysfs based arch independent cpuinfo framework
  x86 cpuinfo: implement sysfs nodes for x86
  arm64 cpuinfo: implement sysfs nodes for arm64

 Documentation/ABI/testing/sysfs-devices-system-cpu | 52 ++++++++++++
 arch/Kconfig                                       | 11 +++
 arch/arm64/Kconfig                                 |  1 +
 arch/arm64/kernel/cpuinfo.c                        | 55 ++++++++++++
 arch/x86/Kconfig                                   |  1 +
 arch/x86/kernel/Makefile                           |  2 +
 arch/x86/kernel/cpuinfo.c                          | 99 ++++++++++++++++++++++
 drivers/base/Makefile                              |  1 +
 drivers/base/cpuinfo.c                             | 48 +++++++++++
 include/linux/cpuhotplug.h                         |  1 +
 include/linux/cpuinfo.h                            | 43 ++++++++++
 11 files changed, 314 insertions(+)
 create mode 100644 arch/x86/kernel/cpuinfo.c
 create mode 100644 drivers/base/cpuinfo.c
 create mode 100644 include/linux/cpuinfo.h

-- 
2.16.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework

[Thomas Renninger]

From: Felix Schnizlein <fschnizlein@suse.de>

Create a new sysfs attribute group called 'info' for each
online cpu. The cleaned up cpuinfo shows up in a sysfs
subdirectory here: /sys/devices/system/cpu/cpu#/info.

Define preprocessor macros (CPUINFO_DEFINE_* and CPUINFO_ATTR) to make
defining new sysfs attributes for cpuinfo more easy.

Add basic documentation for the info sysfs tree.

Signed-off-by: Felix Schnizlein <fschnizlein@suse.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
---
 Documentation/ABI/testing/sysfs-devices-system-cpu |  7 ++++
 arch/Kconfig                                       | 11 +++++
 drivers/base/Makefile                              |  1 +
 drivers/base/cpuinfo.c                             | 48 ++++++++++++++++++++++
 include/linux/cpuhotplug.h                         |  1 +
 include/linux/cpuinfo.h                            | 43 +++++++++++++++++++
 6 files changed, 111 insertions(+)
 create mode 100644 drivers/base/cpuinfo.c
 create mode 100644 include/linux/cpuinfo.h

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index fc20cde63d1e..84c324773b36 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -574,3 +574,10 @@ Description:	Secure Virtual Machine
 		If 1, it means the system is using the Protected Execution
 		Facility in POWER9 and newer processors. i.e., it is a Secure
 		Virtual Machine.
+
+What:		/sys/devices/system/cpu/cpu#/info/
+Date:		June 2019
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Various information about the online cpu. Which attributes are
+		available depends on the architecture, kernel configuration and
+		cpu model.
diff --git a/arch/Kconfig b/arch/Kconfig
index 48b5e103bdb0..39015570b1ca 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -882,6 +882,17 @@ config STRICT_MODULE_RWX
 	  and non-text memory will be made non-executable. This provides
 	  protection against certain security exploits (e.g. writing to text)
 
+config CPUINFO_SYSFS
+	bool "Provides processor information in sysfs. Successor of /proc/cpuinfo"
+	def_bool y
+	depends on HAVE_CPUINFO_SYSFS
+	help
+	  Provides architecture specific processor information in /sys/devices/system/cpu/info
+	  Use this instead of /proc/cpuinfo
+
+config HAVE_CPUINFO_SYSFS
+	bool
+
 # select if the architecture provides an asm/dma-direct.h header
 config ARCH_HAS_PHYS_TO_DMA
 	bool
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 4db2e8f1a1f4..68701f94774c 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_PINCTRL) += pinctrl.o
 obj-$(CONFIG_DEV_COREDUMP) += devcoredump.o
 obj-$(CONFIG_GENERIC_MSI_IRQ_DOMAIN) += platform-msi.o
 obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
+obj-$(CONFIG_CPUINFO_SYSFS) += cpuinfo.o
 
 obj-y			+= test/
 
diff --git a/drivers/base/cpuinfo.c b/drivers/base/cpuinfo.c
new file mode 100644
index 000000000000..09b554d09bfa
--- /dev/null
+++ b/drivers/base/cpuinfo.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2017 SUSE Linux GmbH
+ * Written by: Felix Schnizlein <fschnizlein@suse.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include <linux/cpu.h>
+#include <linux/module.h>
+#include <linux/cpuinfo.h>
+
+static struct attribute_group cpuinfo_attr_group = {
+	.attrs = cpuinfo_attrs,
+	.name = "info"
+};
+
+static int cpuinfo_add_dev(unsigned int cpu)
+{
+	struct device *dev = get_cpu_device(cpu);
+
+	return sysfs_create_group(&dev->kobj, &cpuinfo_attr_group);
+}
+
+static int cpuinfo_remove_dev(unsigned int cpu)
+{
+	struct device *dev = get_cpu_device(cpu);
+
+	sysfs_remove_group(&dev->kobj, &cpuinfo_attr_group);
+	return 0;
+}
+
+static int cpuinfo_sysfs_init(void)
+{
+	return cpuhp_setup_state(CPUHP_CPUINFO_PREPARE,
+				 "base/cpuinfo:prepare",
+				 cpuinfo_add_dev,
+				 cpuinfo_remove_dev);
+}
+
+device_initcall(cpuinfo_sysfs_init);
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index e51ee772b9f5..2c4c59304bdb 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -78,6 +78,7 @@ enum cpuhp_state {
 	CPUHP_SH_SH3X_PREPARE,
 	CPUHP_NET_FLOW_PREPARE,
 	CPUHP_TOPOLOGY_PREPARE,
+	CPUHP_CPUINFO_PREPARE,
 	CPUHP_NET_IUCV_PREPARE,
 	CPUHP_ARM_BL_PREPARE,
 	CPUHP_TRACE_RB_PREPARE,
diff --git a/include/linux/cpuinfo.h b/include/linux/cpuinfo.h
new file mode 100644
index 000000000000..112ff76d64d5
--- /dev/null
+++ b/include/linux/cpuinfo.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2017 SUSE Linux GmbH
+ * Written by: Felix Schnizlein <fschnizlein@suse.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+#ifndef _LINUX_CPUINFO_H
+#define _LINUX_CPUINFO_H
+
+#ifdef CONFIG_HAVE_CPUINFO_SYSFS
+extern struct attribute *cpuinfo_attrs[];
+
+#define CPUINFO_DEFINE_ATTR(name, format)				\
+static ssize_t name##_show(struct device *dev,				\
+			   struct device_attribute *attr,		\
+			   char *buf)					\
+{									\
+	return sprintf(buf, format"\n", cpuinfo_##name(dev->id));	\
+}									\
+static DEVICE_ATTR_RO(name)
+
+
+#define CPUINFO_DEFINE_ATTR_FUNC(name)					\
+static ssize_t name##_show(struct device *dev,				\
+			   struct device_attribute *attr,		\
+			   char *buf)					\
+{									\
+	return cpuinfo_##name(dev->id, buf);				\
+}									\
+static DEVICE_ATTR_RO(name)
+
+
+#define CPUINFO_ATTR(name)			(&dev_attr_##name.attr)
+#endif /* CONFIG_HAVE_CPUINFO_SYSFS */
+
+#endif /* _LINUX_CPUINFO_H */
-- 
2.16.4

[PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework

[Thomas Renninger]

From: Felix Schnizlein <fschnizlein@suse.de>

Create a new sysfs attribute group called 'info' for each
online cpu. The cleaned up cpuinfo shows up in a sysfs
subdirectory here: /sys/devices/system/cpu/cpu#/info.

Define preprocessor macros (CPUINFO_DEFINE_* and CPUINFO_ATTR) to make
defining new sysfs attributes for cpuinfo more easy.

Add basic documentation for the info sysfs tree.

Signed-off-by: Felix Schnizlein <fschnizlein@suse.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
---
 Documentation/ABI/testing/sysfs-devices-system-cpu |  7 ++++
 arch/Kconfig                                       | 11 +++++
 drivers/base/Makefile                              |  1 +
 drivers/base/cpuinfo.c                             | 48 ++++++++++++++++++++++
 include/linux/cpuhotplug.h                         |  1 +
 include/linux/cpuinfo.h                            | 43 +++++++++++++++++++
 6 files changed, 111 insertions(+)
 create mode 100644 drivers/base/cpuinfo.c
 create mode 100644 include/linux/cpuinfo.h

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index fc20cde63d1e..84c324773b36 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -574,3 +574,10 @@ Description:	Secure Virtual Machine
 		If 1, it means the system is using the Protected Execution
 		Facility in POWER9 and newer processors. i.e., it is a Secure
 		Virtual Machine.
+
+What:		/sys/devices/system/cpu/cpu#/info/
+Date:		June 2019
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Various information about the online cpu. Which attributes are
+		available depends on the architecture, kernel configuration and
+		cpu model.
diff --git a/arch/Kconfig b/arch/Kconfig
index 48b5e103bdb0..39015570b1ca 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -882,6 +882,17 @@ config STRICT_MODULE_RWX
 	  and non-text memory will be made non-executable. This provides
 	  protection against certain security exploits (e.g. writing to text)
 
+config CPUINFO_SYSFS
+	bool "Provides processor information in sysfs. Successor of /proc/cpuinfo"
+	def_bool y
+	depends on HAVE_CPUINFO_SYSFS
+	help
+	  Provides architecture specific processor information in /sys/devices/system/cpu/info
+	  Use this instead of /proc/cpuinfo
+
+config HAVE_CPUINFO_SYSFS
+	bool
+
 # select if the architecture provides an asm/dma-direct.h header
 config ARCH_HAS_PHYS_TO_DMA
 	bool
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 4db2e8f1a1f4..68701f94774c 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_PINCTRL) += pinctrl.o
 obj-$(CONFIG_DEV_COREDUMP) += devcoredump.o
 obj-$(CONFIG_GENERIC_MSI_IRQ_DOMAIN) += platform-msi.o
 obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
+obj-$(CONFIG_CPUINFO_SYSFS) += cpuinfo.o
 
 obj-y			+= test/
 
diff --git a/drivers/base/cpuinfo.c b/drivers/base/cpuinfo.c
new file mode 100644
index 000000000000..09b554d09bfa
--- /dev/null
+++ b/drivers/base/cpuinfo.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2017 SUSE Linux GmbH
+ * Written by: Felix Schnizlein <fschnizlein@suse.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include <linux/cpu.h>
+#include <linux/module.h>
+#include <linux/cpuinfo.h>
+
+static struct attribute_group cpuinfo_attr_group = {
+	.attrs = cpuinfo_attrs,
+	.name = "info"
+};
+
+static int cpuinfo_add_dev(unsigned int cpu)
+{
+	struct device *dev = get_cpu_device(cpu);
+
+	return sysfs_create_group(&dev->kobj, &cpuinfo_attr_group);
+}
+
+static int cpuinfo_remove_dev(unsigned int cpu)
+{
+	struct device *dev = get_cpu_device(cpu);
+
+	sysfs_remove_group(&dev->kobj, &cpuinfo_attr_group);
+	return 0;
+}
+
+static int cpuinfo_sysfs_init(void)
+{
+	return cpuhp_setup_state(CPUHP_CPUINFO_PREPARE,
+				 "base/cpuinfo:prepare",
+				 cpuinfo_add_dev,
+				 cpuinfo_remove_dev);
+}
+
+device_initcall(cpuinfo_sysfs_init);
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index e51ee772b9f5..2c4c59304bdb 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -78,6 +78,7 @@ enum cpuhp_state {
 	CPUHP_SH_SH3X_PREPARE,
 	CPUHP_NET_FLOW_PREPARE,
 	CPUHP_TOPOLOGY_PREPARE,
+	CPUHP_CPUINFO_PREPARE,
 	CPUHP_NET_IUCV_PREPARE,
 	CPUHP_ARM_BL_PREPARE,
 	CPUHP_TRACE_RB_PREPARE,
diff --git a/include/linux/cpuinfo.h b/include/linux/cpuinfo.h
new file mode 100644
index 000000000000..112ff76d64d5
--- /dev/null
+++ b/include/linux/cpuinfo.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2017 SUSE Linux GmbH
+ * Written by: Felix Schnizlein <fschnizlein@suse.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+#ifndef _LINUX_CPUINFO_H
+#define _LINUX_CPUINFO_H
+
+#ifdef CONFIG_HAVE_CPUINFO_SYSFS
+extern struct attribute *cpuinfo_attrs[];
+
+#define CPUINFO_DEFINE_ATTR(name, format)				\
+static ssize_t name##_show(struct device *dev,				\
+			   struct device_attribute *attr,		\
+			   char *buf)					\
+{									\
+	return sprintf(buf, format"\n", cpuinfo_##name(dev->id));	\
+}									\
+static DEVICE_ATTR_RO(name)
+
+
+#define CPUINFO_DEFINE_ATTR_FUNC(name)					\
+static ssize_t name##_show(struct device *dev,				\
+			   struct device_attribute *attr,		\
+			   char *buf)					\
+{									\
+	return cpuinfo_##name(dev->id, buf);				\
+}									\
+static DEVICE_ATTR_RO(name)
+
+
+#define CPUINFO_ATTR(name)			(&dev_attr_##name.attr)
+#endif /* CONFIG_HAVE_CPUINFO_SYSFS */
+
+#endif /* _LINUX_CPUINFO_H */
-- 
2.16.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Renninger]

From: Felix Schnizlein <fschnizlein@suse.de>

Enable sysfs cpuinfo for x86 based cpus.
Export often used cpu information to sysfs:
stepping, flags, bugs, bogomips, family, vendor_id,
model, and model_name are exported.

Sysfs documentation is updated to reflect changes.

Example (on a kvm instance running no an intel cpu):
/sys/devices/system/cpu/cpu1/info/:[0]# head *
==> bogomips <==
5187.72

==> bugs <==
cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit

==> cpu_family <==
6

==> flags <==
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip

==> model <==
60

==> model_name <==
Intel Core Processor (Haswell, no TSX, IBRS)

==> stepping <==
1

==> vendor_id <==
GenuineIntel

Signed-off-by: Felix Schnizlein <fschnizlein@suse.com>
Signed-off-by: Thomas Renninger <trenn@suse.com>
---
 Documentation/ABI/testing/sysfs-devices-system-cpu | 23 +++++
 arch/x86/Kconfig                                   |  1 +
 arch/x86/kernel/Makefile                           |  2 +
 arch/x86/kernel/cpuinfo.c                          | 99 ++++++++++++++++++++++
 4 files changed, 125 insertions(+)
 create mode 100644 arch/x86/kernel/cpuinfo.c

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 84c324773b36..791390ab66d5 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -581,3 +581,26 @@ Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
 Description:	Various information about the online cpu. Which attributes are
 		available depends on the architecture, kernel configuration and
 		cpu model.
+
+What:		/sys/devices/system/cpu/cpu#/info/
+		/sys/devices/system/cpu/cpu#/info/vendor_id
+		/sys/devices/system/cpu/cpu#/info/cpu_family
+		/sys/devices/system/cpu/cpu#/info/model
+		/sys/devices/system/cpu/cpu#/info/model_name
+		/sys/devices/system/cpu/cpu#/info/stepping
+		/sys/devices/system/cpu/cpu#/info/flags
+		/sys/devices/system/cpu/cpu#/info/bugs
+		/sys/devices/system/cpu/cpu#/info/bogomips
+Date:		June 2017
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Expose information about x86 cpu information.
+
+		vendor_id,
+		cpu_family,
+		model,
+		model_name,
+		stepping: Cpu identification depending on each vendor
+
+		flags: Extended capabilities supported by the cpu
+		bugs: Known bugs by cpu
+		bogomips: calculated bogomips
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8529a9dbd5ca..29fadd69d541 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -154,6 +154,7 @@ config X86
 	select HAVE_CMPXCHG_LOCAL
 	select HAVE_CONTEXT_TRACKING		if X86_64
 	select HAVE_COPY_THREAD_TLS
+	select HAVE_CPUINFO_SYSFS		if SYSFS
 	select HAVE_C_RECORDMCOUNT
 	select HAVE_DEBUG_KMEMLEAK
 	select HAVE_DMA_CONTIGUOUS
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index ccb13271895d..ccf1a338bc37 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -146,6 +146,8 @@ obj-$(CONFIG_UNWINDER_ORC)		+= unwind_orc.o
 obj-$(CONFIG_UNWINDER_FRAME_POINTER)	+= unwind_frame.o
 obj-$(CONFIG_UNWINDER_GUESS)		+= unwind_guess.o
 
+obj-$(CONFIG_CPUINFO_SYSFS)		+= cpuinfo.o
+
 ###
 # 64 bit specific files
 ifeq ($(CONFIG_X86_64),y)
diff --git a/arch/x86/kernel/cpuinfo.c b/arch/x86/kernel/cpuinfo.c
new file mode 100644
index 000000000000..3b772faf9f5f
--- /dev/null
+++ b/arch/x86/kernel/cpuinfo.c
@@ -0,0 +1,99 @@
+/*
+ * Copyright (C) 2017 SUSE Linux GmbH
+ * Written by: Felix Schnizlein <fschnizlein@suse.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include <linux/cpu.h>
+#include <linux/cpuinfo.h>
+#include <linux/cpufreq.h>
+#include <linux/smp.h>
+
+static ssize_t cpuinfo_stepping(unsigned int c, char *buf)
+{
+	if (cpu_data(c).x86_stepping || cpu_data(c).cpuid_level >= 0)
+		return sprintf(buf, "%d\n", cpu_data(c).x86_stepping);
+	return sprintf(buf, "unknown\n");
+}
+
+static ssize_t cpuinfo_flags(unsigned int c, char *buf)
+{
+	struct cpuinfo_x86 *cpu = &cpu_data(c);
+	unsigned int i;
+	ssize_t len = 0;
+
+	for (i = 0; i < (32 * NCAPINTS); i++) {
+		if (cpu_has(cpu, i) && x86_cap_flags[i] != NULL)
+			len += sprintf(buf+len, len == 0 ? "%s" : " %s",
+				       x86_cap_flags[i]);
+	}
+	if (!len)
+		return 0;
+	return len + sprintf(buf+len, "\n");
+}
+
+static ssize_t cpuinfo_bugs(unsigned int c, char *buf)
+{
+	struct cpuinfo_x86 *cpu = &cpu_data(c);
+	unsigned int i;
+	ssize_t len = 0;
+
+	for (i = 0; i < 32*NBUGINTS; i++) {
+		unsigned int bug_bit = 32*NCAPINTS + i;
+
+		if (cpu_has_bug(cpu, bug_bit) && x86_bug_flags[i])
+			len += sprintf(buf+len, len == 0 ? "%s" : " %s",
+				       x86_bug_flags[i]);
+	}
+	if (!len)
+		return 0;
+	return len + sprintf(buf+len, "\n");
+}
+
+static ssize_t cpuinfo_bogomips(unsigned int c, char *buf)
+{
+	struct cpuinfo_x86 cpu = cpu_data(c);
+
+	return sprintf(buf, "%lu.%02lu\n", cpu.loops_per_jiffy / (500000 / HZ),
+		       (cpu.loops_per_jiffy / (5000 / HZ)) % 100);
+}
+
+#define cpuinfo_cpu_family(cpu)		cpu_data(cpu).x86
+#define cpuinfo_model(cpu)		cpu_data(cpu).x86_model
+
+#define cpuinfo_vendor_id(cpu)		cpu_data(cpu).x86_vendor_id[0] ?\
+	cpu_data(cpu).x86_vendor_id : "unknown"
+
+#define cpuinfo_model_name(cpu)		cpu_data(cpu).x86_model_id[0] ? \
+	cpu_data(cpu).x86_model_id : "unknown"
+
+CPUINFO_DEFINE_ATTR(cpu_family, "%d");
+CPUINFO_DEFINE_ATTR(model, "%u");
+CPUINFO_DEFINE_ATTR(vendor_id, "%s");
+CPUINFO_DEFINE_ATTR(model_name, "%s");
+
+CPUINFO_DEFINE_ATTR_FUNC(stepping);
+CPUINFO_DEFINE_ATTR_FUNC(flags);
+CPUINFO_DEFINE_ATTR_FUNC(bugs);
+CPUINFO_DEFINE_ATTR_FUNC(bogomips);
+
+struct attribute *cpuinfo_attrs[] = {
+	CPUINFO_ATTR(vendor_id),
+	CPUINFO_ATTR(cpu_family),
+	CPUINFO_ATTR(model),
+	CPUINFO_ATTR(model_name),
+	CPUINFO_ATTR(stepping),
+	CPUINFO_ATTR(flags),
+	CPUINFO_ATTR(bugs),
+	CPUINFO_ATTR(bogomips),
+	NULL
+};
-- 
2.16.4

[PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Renninger]

From: Felix Schnizlein <fschnizlein@suse.de>

Enable sysfs cpuinfo for x86 based cpus.
Export often used cpu information to sysfs:
stepping, flags, bugs, bogomips, family, vendor_id,
model, and model_name are exported.

Sysfs documentation is updated to reflect changes.

Example (on a kvm instance running no an intel cpu):
/sys/devices/system/cpu/cpu1/info/:[0]# head *
==> bogomips <==
5187.72

==> bugs <==
cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit

==> cpu_family <==
6

==> flags <==
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip

==> model <==
60

==> model_name <==
Intel Core Processor (Haswell, no TSX, IBRS)

==> stepping <==
1

==> vendor_id <==
GenuineIntel

Signed-off-by: Felix Schnizlein <fschnizlein@suse.com>
Signed-off-by: Thomas Renninger <trenn@suse.com>
---
 Documentation/ABI/testing/sysfs-devices-system-cpu | 23 +++++
 arch/x86/Kconfig                                   |  1 +
 arch/x86/kernel/Makefile                           |  2 +
 arch/x86/kernel/cpuinfo.c                          | 99 ++++++++++++++++++++++
 4 files changed, 125 insertions(+)
 create mode 100644 arch/x86/kernel/cpuinfo.c

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 84c324773b36..791390ab66d5 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -581,3 +581,26 @@ Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
 Description:	Various information about the online cpu. Which attributes are
 		available depends on the architecture, kernel configuration and
 		cpu model.
+
+What:		/sys/devices/system/cpu/cpu#/info/
+		/sys/devices/system/cpu/cpu#/info/vendor_id
+		/sys/devices/system/cpu/cpu#/info/cpu_family
+		/sys/devices/system/cpu/cpu#/info/model
+		/sys/devices/system/cpu/cpu#/info/model_name
+		/sys/devices/system/cpu/cpu#/info/stepping
+		/sys/devices/system/cpu/cpu#/info/flags
+		/sys/devices/system/cpu/cpu#/info/bugs
+		/sys/devices/system/cpu/cpu#/info/bogomips
+Date:		June 2017
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Expose information about x86 cpu information.
+
+		vendor_id,
+		cpu_family,
+		model,
+		model_name,
+		stepping: Cpu identification depending on each vendor
+
+		flags: Extended capabilities supported by the cpu
+		bugs: Known bugs by cpu
+		bogomips: calculated bogomips
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8529a9dbd5ca..29fadd69d541 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -154,6 +154,7 @@ config X86
 	select HAVE_CMPXCHG_LOCAL
 	select HAVE_CONTEXT_TRACKING		if X86_64
 	select HAVE_COPY_THREAD_TLS
+	select HAVE_CPUINFO_SYSFS		if SYSFS
 	select HAVE_C_RECORDMCOUNT
 	select HAVE_DEBUG_KMEMLEAK
 	select HAVE_DMA_CONTIGUOUS
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index ccb13271895d..ccf1a338bc37 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -146,6 +146,8 @@ obj-$(CONFIG_UNWINDER_ORC)		+= unwind_orc.o
 obj-$(CONFIG_UNWINDER_FRAME_POINTER)	+= unwind_frame.o
 obj-$(CONFIG_UNWINDER_GUESS)		+= unwind_guess.o
 
+obj-$(CONFIG_CPUINFO_SYSFS)		+= cpuinfo.o
+
 ###
 # 64 bit specific files
 ifeq ($(CONFIG_X86_64),y)
diff --git a/arch/x86/kernel/cpuinfo.c b/arch/x86/kernel/cpuinfo.c
new file mode 100644
index 000000000000..3b772faf9f5f
--- /dev/null
+++ b/arch/x86/kernel/cpuinfo.c
@@ -0,0 +1,99 @@
+/*
+ * Copyright (C) 2017 SUSE Linux GmbH
+ * Written by: Felix Schnizlein <fschnizlein@suse.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include <linux/cpu.h>
+#include <linux/cpuinfo.h>
+#include <linux/cpufreq.h>
+#include <linux/smp.h>
+
+static ssize_t cpuinfo_stepping(unsigned int c, char *buf)
+{
+	if (cpu_data(c).x86_stepping || cpu_data(c).cpuid_level >= 0)
+		return sprintf(buf, "%d\n", cpu_data(c).x86_stepping);
+	return sprintf(buf, "unknown\n");
+}
+
+static ssize_t cpuinfo_flags(unsigned int c, char *buf)
+{
+	struct cpuinfo_x86 *cpu = &cpu_data(c);
+	unsigned int i;
+	ssize_t len = 0;
+
+	for (i = 0; i < (32 * NCAPINTS); i++) {
+		if (cpu_has(cpu, i) && x86_cap_flags[i] != NULL)
+			len += sprintf(buf+len, len == 0 ? "%s" : " %s",
+				       x86_cap_flags[i]);
+	}
+	if (!len)
+		return 0;
+	return len + sprintf(buf+len, "\n");
+}
+
+static ssize_t cpuinfo_bugs(unsigned int c, char *buf)
+{
+	struct cpuinfo_x86 *cpu = &cpu_data(c);
+	unsigned int i;
+	ssize_t len = 0;
+
+	for (i = 0; i < 32*NBUGINTS; i++) {
+		unsigned int bug_bit = 32*NCAPINTS + i;
+
+		if (cpu_has_bug(cpu, bug_bit) && x86_bug_flags[i])
+			len += sprintf(buf+len, len == 0 ? "%s" : " %s",
+				       x86_bug_flags[i]);
+	}
+	if (!len)
+		return 0;
+	return len + sprintf(buf+len, "\n");
+}
+
+static ssize_t cpuinfo_bogomips(unsigned int c, char *buf)
+{
+	struct cpuinfo_x86 cpu = cpu_data(c);
+
+	return sprintf(buf, "%lu.%02lu\n", cpu.loops_per_jiffy / (500000 / HZ),
+		       (cpu.loops_per_jiffy / (5000 / HZ)) % 100);
+}
+
+#define cpuinfo_cpu_family(cpu)		cpu_data(cpu).x86
+#define cpuinfo_model(cpu)		cpu_data(cpu).x86_model
+
+#define cpuinfo_vendor_id(cpu)		cpu_data(cpu).x86_vendor_id[0] ?\
+	cpu_data(cpu).x86_vendor_id : "unknown"
+
+#define cpuinfo_model_name(cpu)		cpu_data(cpu).x86_model_id[0] ? \
+	cpu_data(cpu).x86_model_id : "unknown"
+
+CPUINFO_DEFINE_ATTR(cpu_family, "%d");
+CPUINFO_DEFINE_ATTR(model, "%u");
+CPUINFO_DEFINE_ATTR(vendor_id, "%s");
+CPUINFO_DEFINE_ATTR(model_name, "%s");
+
+CPUINFO_DEFINE_ATTR_FUNC(stepping);
+CPUINFO_DEFINE_ATTR_FUNC(flags);
+CPUINFO_DEFINE_ATTR_FUNC(bugs);
+CPUINFO_DEFINE_ATTR_FUNC(bogomips);
+
+struct attribute *cpuinfo_attrs[] = {
+	CPUINFO_ATTR(vendor_id),
+	CPUINFO_ATTR(cpu_family),
+	CPUINFO_ATTR(model),
+	CPUINFO_ATTR(model_name),
+	CPUINFO_ATTR(stepping),
+	CPUINFO_ATTR(flags),
+	CPUINFO_ATTR(bugs),
+	CPUINFO_ATTR(bogomips),
+	NULL
+};
-- 
2.16.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Thomas Renninger]

From: Felix Schnizlein <fschnizlein@suse.de>

Export all information from /proc/cpuinfo to sysfs:
implementer, architecture, variant, part, revision,
bogomips and flags are exported.

Example:
/sys/devices/system/cpu/cpu1/info/:[0]# head *
==> architecture <==
8

==> bogomips <==
40.00

==> flags <==
fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm

==> implementer <==
0x51

==> part <==
0xc00

==> revision <==
1

==> variant <==
0x0

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Felix Schnizlein <fschnizlein@suse.com>
---
 Documentation/ABI/testing/sysfs-devices-system-cpu | 22 +++++++++
 arch/arm64/Kconfig                                 |  1 +
 arch/arm64/kernel/cpuinfo.c                        | 55 ++++++++++++++++++++++
 3 files changed, 78 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 791390ab66d5..b6a167cd0beb 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -604,3 +604,25 @@ Description:	Expose information about x86 cpu information.
 		flags: Extended capabilities supported by the cpu
 		bugs: Known bugs by cpu
 		bogomips: calculated bogomips
+
+
+What:		/sys/devices/system/cpu/cpu#/info/
+		/sys/devices/system/cpu/cpu#/info/implementer
+		/sys/devices/system/cpu/cpu#/info/architecture
+		/sys/devices/system/cpu/cpu#/info/variant
+		/sys/devices/system/cpu/cpu#/info/part
+		/sys/devices/system/cpu/cpu#/info/revision
+		/sys/devices/system/cpu/cpu#/info/flags
+		/sys/devices/system/cpu/cpu#/info/bogomips
+Date:		August 2017
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Expose information about arm64 cpu.
+
+		implementer,
+		architecture,
+		variant,
+		part,
+		revision: Cpu identification depending on each vendor
+
+		flags: Extended capabilities supported by the cpu
+		bogomips: calculated bogomips
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43aa1de727f4..0e8f7733e8c3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -169,6 +169,7 @@ config ARM64
 	select HAVE_KPROBES
 	select HAVE_KRETPROBES
 	select HAVE_GENERIC_VDSO
+	select HAVE_CPUINFO_SYSFS if SYSFS
 	select IOMMU_DMA if IOMMU_SUPPORT
 	select IRQ_DOMAIN
 	select IRQ_FORCED_THREADING
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 56bba746da1c..d142e2d37ead 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -24,6 +24,7 @@
 #include <linux/sched.h>
 #include <linux/smp.h>
 #include <linux/delay.h>
+#include <linux/cpuinfo.h>
 
 /*
  * In case the boot CPU is hotpluggable, we record its initial state and
@@ -33,6 +34,8 @@
 DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
 static struct cpuinfo_arm64 boot_cpu_data;
 
+#define cpu_data(cpu)			per_cpu(cpu_data, cpu)
+
 static const char *icache_policy_str[] = {
 	[0 ... ICACHE_POLICY_PIPT]	= "RESERVED/UNKNOWN",
 	[ICACHE_POLICY_VIPT]		= "VIPT",
@@ -285,6 +288,58 @@ static int cpuid_cpu_offline(unsigned int cpu)
 	return 0;
 }
 
+#ifdef CONFIG_HAVE_CPUINFO_SYSFS
+
+#define cpuinfo_implementer(cpu)	MIDR_IMPLEMENTOR(cpu_data(cpu).reg_midr)
+#define cpuinfo_architecture(cpu)	"8"
+#define cpuinfo_variant(cpu)		MIDR_VARIANT(cpu_data(cpu).reg_midr)
+#define cpuinfo_part(cpu)		MIDR_PARTNUM(cpu_data(cpu).reg_midr)
+#define cpuinfo_revision(cpu)		MIDR_REVISION(cpu_data(cpu).reg_midr)
+
+static ssize_t cpuinfo_flags(unsigned int c, char *buf)
+{
+	unsigned int i;
+	ssize_t len = 0;
+
+	for (i = 0; hwcap_str[i]; i++) {
+		if (cpu_have_feature(i))
+			len += sprintf(buf+len, len == 0 ? "%s" : " %s",
+				       hwcap_str[i]);
+	}
+	if (!len)
+		return 0;
+	return len + sprintf(buf+len, "\n");
+}
+
+static ssize_t cpuinfo_bogomips(unsigned int c, char *buf)
+{
+	return sprintf(buf, "%lu.%02lu\n", loops_per_jiffy / (500000 / HZ),
+		       (loops_per_jiffy / (5000 / HZ)) % 100);
+
+}
+
+CPUINFO_DEFINE_ATTR(implementer, "0x%02x");
+CPUINFO_DEFINE_ATTR(architecture, "%s");
+CPUINFO_DEFINE_ATTR(variant, "0x%x");
+CPUINFO_DEFINE_ATTR(part, "0x%03x");
+CPUINFO_DEFINE_ATTR(revision, "%d");
+
+CPUINFO_DEFINE_ATTR_FUNC(bogomips);
+CPUINFO_DEFINE_ATTR_FUNC(flags);
+
+struct attribute *cpuinfo_attrs[] = {
+	CPUINFO_ATTR(implementer),
+	CPUINFO_ATTR(architecture),
+	CPUINFO_ATTR(variant),
+	CPUINFO_ATTR(part),
+	CPUINFO_ATTR(revision),
+	CPUINFO_ATTR(bogomips),
+	CPUINFO_ATTR(flags),
+	NULL
+};
+#endif /* CONFIG_HAVE_CPUINFO_SYSFS */
+
+
 static int __init cpuinfo_regs_init(void)
 {
 	int cpu, ret;
-- 
2.16.4

[PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Thomas Renninger]

From: Felix Schnizlein <fschnizlein@suse.de>

Export all information from /proc/cpuinfo to sysfs:
implementer, architecture, variant, part, revision,
bogomips and flags are exported.

Example:
/sys/devices/system/cpu/cpu1/info/:[0]# head *
==> architecture <==
8

==> bogomips <==
40.00

==> flags <==
fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm

==> implementer <==
0x51

==> part <==
0xc00

==> revision <==
1

==> variant <==
0x0

Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Felix Schnizlein <fschnizlein@suse.com>
---
 Documentation/ABI/testing/sysfs-devices-system-cpu | 22 +++++++++
 arch/arm64/Kconfig                                 |  1 +
 arch/arm64/kernel/cpuinfo.c                        | 55 ++++++++++++++++++++++
 3 files changed, 78 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 791390ab66d5..b6a167cd0beb 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -604,3 +604,25 @@ Description:	Expose information about x86 cpu information.
 		flags: Extended capabilities supported by the cpu
 		bugs: Known bugs by cpu
 		bogomips: calculated bogomips
+
+
+What:		/sys/devices/system/cpu/cpu#/info/
+		/sys/devices/system/cpu/cpu#/info/implementer
+		/sys/devices/system/cpu/cpu#/info/architecture
+		/sys/devices/system/cpu/cpu#/info/variant
+		/sys/devices/system/cpu/cpu#/info/part
+		/sys/devices/system/cpu/cpu#/info/revision
+		/sys/devices/system/cpu/cpu#/info/flags
+		/sys/devices/system/cpu/cpu#/info/bogomips
+Date:		August 2017
+Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
+Description:	Expose information about arm64 cpu.
+
+		implementer,
+		architecture,
+		variant,
+		part,
+		revision: Cpu identification depending on each vendor
+
+		flags: Extended capabilities supported by the cpu
+		bogomips: calculated bogomips
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 43aa1de727f4..0e8f7733e8c3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -169,6 +169,7 @@ config ARM64
 	select HAVE_KPROBES
 	select HAVE_KRETPROBES
 	select HAVE_GENERIC_VDSO
+	select HAVE_CPUINFO_SYSFS if SYSFS
 	select IOMMU_DMA if IOMMU_SUPPORT
 	select IRQ_DOMAIN
 	select IRQ_FORCED_THREADING
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 56bba746da1c..d142e2d37ead 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -24,6 +24,7 @@
 #include <linux/sched.h>
 #include <linux/smp.h>
 #include <linux/delay.h>
+#include <linux/cpuinfo.h>
 
 /*
  * In case the boot CPU is hotpluggable, we record its initial state and
@@ -33,6 +34,8 @@
 DEFINE_PER_CPU(struct cpuinfo_arm64, cpu_data);
 static struct cpuinfo_arm64 boot_cpu_data;
 
+#define cpu_data(cpu)			per_cpu(cpu_data, cpu)
+
 static const char *icache_policy_str[] = {
 	[0 ... ICACHE_POLICY_PIPT]	= "RESERVED/UNKNOWN",
 	[ICACHE_POLICY_VIPT]		= "VIPT",
@@ -285,6 +288,58 @@ static int cpuid_cpu_offline(unsigned int cpu)
 	return 0;
 }
 
+#ifdef CONFIG_HAVE_CPUINFO_SYSFS
+
+#define cpuinfo_implementer(cpu)	MIDR_IMPLEMENTOR(cpu_data(cpu).reg_midr)
+#define cpuinfo_architecture(cpu)	"8"
+#define cpuinfo_variant(cpu)		MIDR_VARIANT(cpu_data(cpu).reg_midr)
+#define cpuinfo_part(cpu)		MIDR_PARTNUM(cpu_data(cpu).reg_midr)
+#define cpuinfo_revision(cpu)		MIDR_REVISION(cpu_data(cpu).reg_midr)
+
+static ssize_t cpuinfo_flags(unsigned int c, char *buf)
+{
+	unsigned int i;
+	ssize_t len = 0;
+
+	for (i = 0; hwcap_str[i]; i++) {
+		if (cpu_have_feature(i))
+			len += sprintf(buf+len, len == 0 ? "%s" : " %s",
+				       hwcap_str[i]);
+	}
+	if (!len)
+		return 0;
+	return len + sprintf(buf+len, "\n");
+}
+
+static ssize_t cpuinfo_bogomips(unsigned int c, char *buf)
+{
+	return sprintf(buf, "%lu.%02lu\n", loops_per_jiffy / (500000 / HZ),
+		       (loops_per_jiffy / (5000 / HZ)) % 100);
+
+}
+
+CPUINFO_DEFINE_ATTR(implementer, "0x%02x");
+CPUINFO_DEFINE_ATTR(architecture, "%s");
+CPUINFO_DEFINE_ATTR(variant, "0x%x");
+CPUINFO_DEFINE_ATTR(part, "0x%03x");
+CPUINFO_DEFINE_ATTR(revision, "%d");
+
+CPUINFO_DEFINE_ATTR_FUNC(bogomips);
+CPUINFO_DEFINE_ATTR_FUNC(flags);
+
+struct attribute *cpuinfo_attrs[] = {
+	CPUINFO_ATTR(implementer),
+	CPUINFO_ATTR(architecture),
+	CPUINFO_ATTR(variant),
+	CPUINFO_ATTR(part),
+	CPUINFO_ATTR(revision),
+	CPUINFO_ATTR(bogomips),
+	CPUINFO_ATTR(flags),
+	NULL
+};
+#endif /* CONFIG_HAVE_CPUINFO_SYSFS */
+
+
 static int __init cpuinfo_regs_init(void)
 {
 	int cpu, ret;
-- 
2.16.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework

[Greg KH]

On Fri, Dec 06, 2019 at 05:24:19PM +0100, Thomas Renninger wrote:
> --- /dev/null
> +++ b/drivers/base/cpuinfo.c
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (C) 2017 SUSE Linux GmbH
> + * Written by: Felix Schnizlein <fschnizlein@suse.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + */

No SPDX line?  And you can drop the license boilerplate text as well
too.

> +
> +#include <linux/cpu.h>
> +#include <linux/module.h>
> +#include <linux/cpuinfo.h>
> +
> +static struct attribute_group cpuinfo_attr_group = {
> +	.attrs = cpuinfo_attrs,
> +	.name = "info"
> +};
> +
> +static int cpuinfo_add_dev(unsigned int cpu)
> +{
> +	struct device *dev = get_cpu_device(cpu);
> +
> +	return sysfs_create_group(&dev->kobj, &cpuinfo_attr_group);

Why are a set of attributes being added _after_ the device is created?
We have fixed up a lot of the "default attribute" logic since 2017,
perhaps you should be using that instead?


> +}
> +
> +static int cpuinfo_remove_dev(unsigned int cpu)
> +{
> +	struct device *dev = get_cpu_device(cpu);
> +
> +	sysfs_remove_group(&dev->kobj, &cpuinfo_attr_group);

Same here, I don't think this is needed.

> +	return 0;
> +}
> +
> +static int cpuinfo_sysfs_init(void)
> +{
> +	return cpuhp_setup_state(CPUHP_CPUINFO_PREPARE,
> +				 "base/cpuinfo:prepare",
> +				 cpuinfo_add_dev,
> +				 cpuinfo_remove_dev);
> +}
> +
> +device_initcall(cpuinfo_sysfs_init);
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index e51ee772b9f5..2c4c59304bdb 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -78,6 +78,7 @@ enum cpuhp_state {
>  	CPUHP_SH_SH3X_PREPARE,
>  	CPUHP_NET_FLOW_PREPARE,
>  	CPUHP_TOPOLOGY_PREPARE,
> +	CPUHP_CPUINFO_PREPARE,
>  	CPUHP_NET_IUCV_PREPARE,
>  	CPUHP_ARM_BL_PREPARE,
>  	CPUHP_TRACE_RB_PREPARE,
> diff --git a/include/linux/cpuinfo.h b/include/linux/cpuinfo.h
> new file mode 100644
> index 000000000000..112ff76d64d5
> --- /dev/null
> +++ b/include/linux/cpuinfo.h
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright (C) 2017 SUSE Linux GmbH
> + * Written by: Felix Schnizlein <fschnizlein@suse.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.

SPDX and boilerplate.


> + */
> +#ifndef _LINUX_CPUINFO_H
> +#define _LINUX_CPUINFO_H
> +
> +#ifdef CONFIG_HAVE_CPUINFO_SYSFS
> +extern struct attribute *cpuinfo_attrs[];

No need for thie #ifdef really, right?

thanks,

greg k-h

Re: [PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework

[Greg KH]

On Fri, Dec 06, 2019 at 05:24:19PM +0100, Thomas Renninger wrote:
> --- /dev/null
> +++ b/drivers/base/cpuinfo.c
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (C) 2017 SUSE Linux GmbH
> + * Written by: Felix Schnizlein <fschnizlein@suse.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + */

No SPDX line?  And you can drop the license boilerplate text as well
too.

> +
> +#include <linux/cpu.h>
> +#include <linux/module.h>
> +#include <linux/cpuinfo.h>
> +
> +static struct attribute_group cpuinfo_attr_group = {
> +	.attrs = cpuinfo_attrs,
> +	.name = "info"
> +};
> +
> +static int cpuinfo_add_dev(unsigned int cpu)
> +{
> +	struct device *dev = get_cpu_device(cpu);
> +
> +	return sysfs_create_group(&dev->kobj, &cpuinfo_attr_group);

Why are a set of attributes being added _after_ the device is created?
We have fixed up a lot of the "default attribute" logic since 2017,
perhaps you should be using that instead?


> +}
> +
> +static int cpuinfo_remove_dev(unsigned int cpu)
> +{
> +	struct device *dev = get_cpu_device(cpu);
> +
> +	sysfs_remove_group(&dev->kobj, &cpuinfo_attr_group);

Same here, I don't think this is needed.

> +	return 0;
> +}
> +
> +static int cpuinfo_sysfs_init(void)
> +{
> +	return cpuhp_setup_state(CPUHP_CPUINFO_PREPARE,
> +				 "base/cpuinfo:prepare",
> +				 cpuinfo_add_dev,
> +				 cpuinfo_remove_dev);
> +}
> +
> +device_initcall(cpuinfo_sysfs_init);
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index e51ee772b9f5..2c4c59304bdb 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -78,6 +78,7 @@ enum cpuhp_state {
>  	CPUHP_SH_SH3X_PREPARE,
>  	CPUHP_NET_FLOW_PREPARE,
>  	CPUHP_TOPOLOGY_PREPARE,
> +	CPUHP_CPUINFO_PREPARE,
>  	CPUHP_NET_IUCV_PREPARE,
>  	CPUHP_ARM_BL_PREPARE,
>  	CPUHP_TRACE_RB_PREPARE,
> diff --git a/include/linux/cpuinfo.h b/include/linux/cpuinfo.h
> new file mode 100644
> index 000000000000..112ff76d64d5
> --- /dev/null
> +++ b/include/linux/cpuinfo.h
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright (C) 2017 SUSE Linux GmbH
> + * Written by: Felix Schnizlein <fschnizlein@suse.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.

SPDX and boilerplate.


> + */
> +#ifndef _LINUX_CPUINFO_H
> +#define _LINUX_CPUINFO_H
> +
> +#ifdef CONFIG_HAVE_CPUINFO_SYSFS
> +extern struct attribute *cpuinfo_attrs[];

No need for thie #ifdef really, right?

thanks,

greg k-h

Re: [PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework

[Greg KH]

On Fri, Dec 06, 2019 at 05:24:19PM +0100, Thomas Renninger wrote:
> --- /dev/null
> +++ b/drivers/base/cpuinfo.c
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (C) 2017 SUSE Linux GmbH
> + * Written by: Felix Schnizlein <fschnizlein@suse.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + */

No SPDX line?  And you can drop the license boilerplate text as well
too.

> +
> +#include <linux/cpu.h>
> +#include <linux/module.h>
> +#include <linux/cpuinfo.h>
> +
> +static struct attribute_group cpuinfo_attr_group = {
> +	.attrs = cpuinfo_attrs,
> +	.name = "info"
> +};
> +
> +static int cpuinfo_add_dev(unsigned int cpu)
> +{
> +	struct device *dev = get_cpu_device(cpu);
> +
> +	return sysfs_create_group(&dev->kobj, &cpuinfo_attr_group);

Why are a set of attributes being added _after_ the device is created?
We have fixed up a lot of the "default attribute" logic since 2017,
perhaps you should be using that instead?


> +}
> +
> +static int cpuinfo_remove_dev(unsigned int cpu)
> +{
> +	struct device *dev = get_cpu_device(cpu);
> +
> +	sysfs_remove_group(&dev->kobj, &cpuinfo_attr_group);

Same here, I don't think this is needed.

> +	return 0;
> +}
> +
> +static int cpuinfo_sysfs_init(void)
> +{
> +	return cpuhp_setup_state(CPUHP_CPUINFO_PREPARE,
> +				 "base/cpuinfo:prepare",
> +				 cpuinfo_add_dev,
> +				 cpuinfo_remove_dev);
> +}
> +
> +device_initcall(cpuinfo_sysfs_init);
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index e51ee772b9f5..2c4c59304bdb 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -78,6 +78,7 @@ enum cpuhp_state {
>  	CPUHP_SH_SH3X_PREPARE,
>  	CPUHP_NET_FLOW_PREPARE,
>  	CPUHP_TOPOLOGY_PREPARE,
> +	CPUHP_CPUINFO_PREPARE,
>  	CPUHP_NET_IUCV_PREPARE,
>  	CPUHP_ARM_BL_PREPARE,
>  	CPUHP_TRACE_RB_PREPARE,
> diff --git a/include/linux/cpuinfo.h b/include/linux/cpuinfo.h
> new file mode 100644
> index 000000000000..112ff76d64d5
> --- /dev/null
> +++ b/include/linux/cpuinfo.h
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright (C) 2017 SUSE Linux GmbH
> + * Written by: Felix Schnizlein <fschnizlein@suse.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.

SPDX and boilerplate.


> + */
> +#ifndef _LINUX_CPUINFO_H
> +#define _LINUX_CPUINFO_H
> +
> +#ifdef CONFIG_HAVE_CPUINFO_SYSFS
> +extern struct attribute *cpuinfo_attrs[];

No need for thie #ifdef really, right?

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
> From: Felix Schnizlein <fschnizlein@suse.de>
> 
> Enable sysfs cpuinfo for x86 based cpus.
> Export often used cpu information to sysfs:
> stepping, flags, bugs, bogomips, family, vendor_id,
> model, and model_name are exported.
> 
> Sysfs documentation is updated to reflect changes.
> 
> Example (on a kvm instance running no an intel cpu):
> /sys/devices/system/cpu/cpu1/info/:[0]# head *
> ==> bogomips <==
> 5187.72
> 
> ==> bugs <==
> cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
> 
> ==> cpu_family <==
> 6
> 
> ==> flags <==
> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip

One file with all of that?  We are going to run into problems
eventually, that should be split up.

Just like bugs, that's going to just grow over time and eventually
overflow PAGE_SIZE :(

Make this:
  ├── flags
  │   ├── fpu
  │   ├── vme
...

Much simpler to parse, right?

sysfs files need to be one-value-per-file, and that's a lot of different
values in a single file.

How did I miss that before?

> @@ -0,0 +1,99 @@
> +/*
> + * Copyright (C) 2017 SUSE Linux GmbH
> + * Written by: Felix Schnizlein <fschnizlein@suse.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.

Boilerplate and SPDX.

You did run these through checkpatch.pl, right?  It should have
complained about this.

thanks,

greg k-h

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
> From: Felix Schnizlein <fschnizlein@suse.de>
> 
> Enable sysfs cpuinfo for x86 based cpus.
> Export often used cpu information to sysfs:
> stepping, flags, bugs, bogomips, family, vendor_id,
> model, and model_name are exported.
> 
> Sysfs documentation is updated to reflect changes.
> 
> Example (on a kvm instance running no an intel cpu):
> /sys/devices/system/cpu/cpu1/info/:[0]# head *
> ==> bogomips <==
> 5187.72
> 
> ==> bugs <==
> cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
> 
> ==> cpu_family <==
> 6
> 
> ==> flags <==
> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip

One file with all of that?  We are going to run into problems
eventually, that should be split up.

Just like bugs, that's going to just grow over time and eventually
overflow PAGE_SIZE :(

Make this:
  ├── flags
  │   ├── fpu
  │   ├── vme
...

Much simpler to parse, right?

sysfs files need to be one-value-per-file, and that's a lot of different
values in a single file.

How did I miss that before?

> @@ -0,0 +1,99 @@
> +/*
> + * Copyright (C) 2017 SUSE Linux GmbH
> + * Written by: Felix Schnizlein <fschnizlein@suse.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.

Boilerplate and SPDX.

You did run these through checkpatch.pl, right?  It should have
complained about this.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Greg KH]

On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> From: Felix Schnizlein <fschnizlein@suse.de>
> 
> Export all information from /proc/cpuinfo to sysfs:
> implementer, architecture, variant, part, revision,
> bogomips and flags are exported.
> 
> Example:
> /sys/devices/system/cpu/cpu1/info/:[0]# head *
> ==> architecture <==
> 8
> 
> ==> bogomips <==
> 40.00
> 
> ==> flags <==
> fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm

Same comments as on the x86 patch :(

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Greg KH]

On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> From: Felix Schnizlein <fschnizlein@suse.de>
> 
> Export all information from /proc/cpuinfo to sysfs:
> implementer, architecture, variant, part, revision,
> bogomips and flags are exported.
> 
> Example:
> /sys/devices/system/cpu/cpu1/info/:[0]# head *
> ==> architecture <==
> 8
> 
> ==> bogomips <==
> 40.00
> 
> ==> flags <==
> fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm

Same comments as on the x86 patch :(

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework

[Randy Dunlap]

On 12/6/19 8:24 AM, Thomas Renninger wrote:
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 48b5e103bdb0..39015570b1ca 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -882,6 +882,17 @@ config STRICT_MODULE_RWX
>  	  and non-text memory will be made non-executable. This provides
>  	  protection against certain security exploits (e.g. writing to text)
>  
> +config CPUINFO_SYSFS
> +	bool "Provides processor information in sysfs. Successor of /proc/cpuinfo"

	      Provide

> +	def_bool y
> +	depends on HAVE_CPUINFO_SYSFS
> +	help
> +	  Provides architecture specific processor information in /sys/devices/system/cpu/info> +	  Use this instead of /proc/cpuinfo

End those 2 sentences with periods (full stop), please.

> +
> +config HAVE_CPUINFO_SYSFS
> +	bool
> +
>  # select if the architecture provides an asm/dma-direct.h header
>  config ARCH_HAS_PHYS_TO_DMA
>  	bool


-- 
~Randy

Re: [PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework

[Randy Dunlap]

On 12/6/19 8:24 AM, Thomas Renninger wrote:
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 48b5e103bdb0..39015570b1ca 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -882,6 +882,17 @@ config STRICT_MODULE_RWX
>  	  and non-text memory will be made non-executable. This provides
>  	  protection against certain security exploits (e.g. writing to text)
>  
> +config CPUINFO_SYSFS
> +	bool "Provides processor information in sysfs. Successor of /proc/cpuinfo"

	      Provide

> +	def_bool y
> +	depends on HAVE_CPUINFO_SYSFS
> +	help
> +	  Provides architecture specific processor information in /sys/devices/system/cpu/info> +	  Use this instead of /proc/cpuinfo

End those 2 sentences with periods (full stop), please.

> +
> +config HAVE_CPUINFO_SYSFS
> +	bool
> +
>  # select if the architecture provides an asm/dma-direct.h header
>  config ARCH_HAS_PHYS_TO_DMA
>  	bool


-- 
~Randy

Re: [PATCH 1/3] cpuinfo: add sysfs based arch independent cpuinfo framework

[Randy Dunlap]

On 12/6/19 8:24 AM, Thomas Renninger wrote:
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 48b5e103bdb0..39015570b1ca 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -882,6 +882,17 @@ config STRICT_MODULE_RWX
>  	  and non-text memory will be made non-executable. This provides
>  	  protection against certain security exploits (e.g. writing to text)
>  
> +config CPUINFO_SYSFS
> +	bool "Provides processor information in sysfs. Successor of /proc/cpuinfo"

	      Provide

> +	def_bool y
> +	depends on HAVE_CPUINFO_SYSFS
> +	help
> +	  Provides architecture specific processor information in /sys/devices/system/cpu/info> +	  Use this instead of /proc/cpuinfo

End those 2 sentences with periods (full stop), please.

> +
> +config HAVE_CPUINFO_SYSFS
> +	bool
> +
>  # select if the architecture provides an asm/dma-direct.h header
>  config ARCH_HAS_PHYS_TO_DMA
>  	bool


-- 
~Randy


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[Mark Rutland]

Hi Thomas,

On Fri, Dec 06, 2019 at 05:24:18PM +0100, Thomas Renninger wrote:
> I picked up Felix Schnizlein's work from 2017.
> 
> It was already reviewed by Greg-KH at this time and even
> pushed into linux-next tree, when it came out that the mails
> never reached lkml, even the list was added to CC.
> 
> ARM people then correctly complained that this needs more review
> by ARCH people. It got reverted, Felix had no time anymore and this
> nice patcheset was hanging around nowhere...

Can you please provide a rationale for this?

It's not entirely clear to me what information people need or want, and
there's some data in /proc/cpuinfo that I think makes no sense to try to
export export in a structured way (e.g. bogomips).

> 
> Tested on aarch64:
> 
> /sys/devices/system/cpu/cpu1/info/:[0]# ls
> architecture  bogomips  flags  implementer  part  revision  variant
> 
> ------------------------------------------------------------
> 
> for file in *;do echo $file; cat $file;echo;done
> architecture
> 8
> 
> bogomips
> 40.00
> 
> flags
> fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> 
> implementer
> 0x51
> 
> part
> 0xc00
> 
> revision
> 1
> 
> variant
> 0x0
 
For arm64 we already expose the MIDR and REVIDR register values under
/sys/devices/system/cpu/cpu*/regs/identification, and that's the bulk of
the useful information above (aside from the flags/hwcaps).

Thanks,
Mark.

Re: [PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[Mark Rutland]

Hi Thomas,

On Fri, Dec 06, 2019 at 05:24:18PM +0100, Thomas Renninger wrote:
> I picked up Felix Schnizlein's work from 2017.
> 
> It was already reviewed by Greg-KH at this time and even
> pushed into linux-next tree, when it came out that the mails
> never reached lkml, even the list was added to CC.
> 
> ARM people then correctly complained that this needs more review
> by ARCH people. It got reverted, Felix had no time anymore and this
> nice patcheset was hanging around nowhere...

Can you please provide a rationale for this?

It's not entirely clear to me what information people need or want, and
there's some data in /proc/cpuinfo that I think makes no sense to try to
export export in a structured way (e.g. bogomips).

> 
> Tested on aarch64:
> 
> /sys/devices/system/cpu/cpu1/info/:[0]# ls
> architecture  bogomips  flags  implementer  part  revision  variant
> 
> ------------------------------------------------------------
> 
> for file in *;do echo $file; cat $file;echo;done
> architecture
> 8
> 
> bogomips
> 40.00
> 
> flags
> fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> 
> implementer
> 0x51
> 
> part
> 0xc00
> 
> revision
> 1
> 
> variant
> 0x0
 
For arm64 we already expose the MIDR and REVIDR register values under
/sys/devices/system/cpu/cpu*/regs/identification, and that's the bulk of
the useful information above (aside from the flags/hwcaps).

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[Thomas Renninger]

On Friday, December 6, 2019 5:58:03 PM CET Mark Rutland wrote:
> Hi Thomas,
> 
> On Fri, Dec 06, 2019 at 05:24:18PM +0100, Thomas Renninger wrote:
> > I picked up Felix Schnizlein's work from 2017.
> > 
> > It was already reviewed by Greg-KH at this time and even
> > pushed into linux-next tree, when it came out that the mails
> > never reached lkml, even the list was added to CC.
> > 
> > ARM people then correctly complained that this needs more review
> > by ARCH people. It got reverted, Felix had no time anymore and this
> > nice patcheset was hanging around nowhere...
> 
> Can you please provide a rationale for this?

/proc moves to /sys. For years already, some data needs longer...

If you compare /proc/cpuinfo between different archs, you realize
that it is rather different and a huge mess of arbitrary info.

It would be great if people think a bit more about this...
What else could show up on which architecture to avoid different
interfaces (sys files) with the same info across architectures.

I'd like to have general CPU identification, and other info like
bugs, flags or whatever info that exists across architectures in one
sysfs file/directory.

arch=$(uname -m)
case $arch in
   x86_64)
      cat /sys/devices/system/cpu/cpu0/info/name
      ;;
   aarch64)
      cat /sys/devices/system/cpu/cpu0/regs/identification
      ::
   ...
esac

This is better than grepping on different identifiers in huge /proc/cpuinfo,
but it still is lame.

Ideal would be:
/sys/devices/system/cpu/cpu0/info/{name,vendor,flags,bugs,base_freq,...}
being avail for all CPUs on all archs.

if it does not exist yet..., it should at least show up there if it gets
implemented at some point of time.

> there's some data in /proc/cpuinfo that I think makes no sense to try to
> export export in a structured way (e.g. bogomips).

I'd be happy to remove bogomips if nobody needs this.

> 
> > Tested on aarch64:
> > 
> > /sys/devices/system/cpu/cpu1/info/:[0]# ls
> > architecture  bogomips  flags  implementer  part  revision  variant
> > 
> > ------------------------------------------------------------
> > 
> > for file in *;do echo $file; cat $file;echo;done
> > architecture
> > 8
> > 
> > bogomips
> > 40.00
> > 
> > flags
> > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> > 
> > implementer
> > 0x51
> > 
> > part
> > 0xc00
> > 
> > revision
> > 1
> > 
> > variant
> > 0x0
> 
> For arm64 we already expose the MIDR and REVIDR register values under
> /sys/devices/system/cpu/cpu*/regs/identification, and that's the bulk of
> the useful information above

I'd like to come up with an extra CONFIG which parses:

arch/arm64/include/asm/cputype.h:

#define ARM_CPU_PART_AEM_V8             0xD0F
#define ARM_CPU_PART_FOUNDATION         0xD00
#define ARM_CPU_PART_CORTEX_A57         0xD07
#define ARM_CPU_PART_CORTEX_A72         0xD08

and

#define ARM_CPU_IMP_ARM                 0x41
#define ARM_CPU_IMP_APM                 0x50
#define ARM_CPU_IMP_CAVIUM              0x43
#define ARM_CPU_IMP_BRCM                0x42
#define ARM_CPU_IMP_QCOM                0x51
#define ARM_CPU_IMP_NVIDIA              0x4E

and converts the defines to strings, same as here:

arch/x86/include/asm/intel-family.h

#define INTEL_FAM6_SKYLAKE_L            0x4E
#define INTEL_FAM6_SKYLAKE              0x5E
#define INTEL_FAM6_SKYLAKE_X            0x55
#define INTEL_FAM6_KABYLAKE_L           0x8E
#define INTEL_FAM6_KABYLAKE             0x9E

and provide the model name (and for ARM the vendor name)
compiled in a module.

At least for aarch64 and x86 it seem to be possible
to get a vendor/model string from the same defined file:
/sys/devices/system/cpu/cpu0/info/{model_name,vendor}


> (aside from the flags/hwcaps).

which make sense to add there, right?

Thanks,

      Thomas

Re: [PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[Thomas Renninger]

On Friday, December 6, 2019 5:58:03 PM CET Mark Rutland wrote:
> Hi Thomas,
> 
> On Fri, Dec 06, 2019 at 05:24:18PM +0100, Thomas Renninger wrote:
> > I picked up Felix Schnizlein's work from 2017.
> > 
> > It was already reviewed by Greg-KH at this time and even
> > pushed into linux-next tree, when it came out that the mails
> > never reached lkml, even the list was added to CC.
> > 
> > ARM people then correctly complained that this needs more review
> > by ARCH people. It got reverted, Felix had no time anymore and this
> > nice patcheset was hanging around nowhere...
> 
> Can you please provide a rationale for this?

/proc moves to /sys. For years already, some data needs longer...

If you compare /proc/cpuinfo between different archs, you realize
that it is rather different and a huge mess of arbitrary info.

It would be great if people think a bit more about this...
What else could show up on which architecture to avoid different
interfaces (sys files) with the same info across architectures.

I'd like to have general CPU identification, and other info like
bugs, flags or whatever info that exists across architectures in one
sysfs file/directory.

arch=$(uname -m)
case $arch in
   x86_64)
      cat /sys/devices/system/cpu/cpu0/info/name
      ;;
   aarch64)
      cat /sys/devices/system/cpu/cpu0/regs/identification
      ::
   ...
esac

This is better than grepping on different identifiers in huge /proc/cpuinfo,
but it still is lame.

Ideal would be:
/sys/devices/system/cpu/cpu0/info/{name,vendor,flags,bugs,base_freq,...}
being avail for all CPUs on all archs.

if it does not exist yet..., it should at least show up there if it gets
implemented at some point of time.

> there's some data in /proc/cpuinfo that I think makes no sense to try to
> export export in a structured way (e.g. bogomips).

I'd be happy to remove bogomips if nobody needs this.

> 
> > Tested on aarch64:
> > 
> > /sys/devices/system/cpu/cpu1/info/:[0]# ls
> > architecture  bogomips  flags  implementer  part  revision  variant
> > 
> > ------------------------------------------------------------
> > 
> > for file in *;do echo $file; cat $file;echo;done
> > architecture
> > 8
> > 
> > bogomips
> > 40.00
> > 
> > flags
> > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> > 
> > implementer
> > 0x51
> > 
> > part
> > 0xc00
> > 
> > revision
> > 1
> > 
> > variant
> > 0x0
> 
> For arm64 we already expose the MIDR and REVIDR register values under
> /sys/devices/system/cpu/cpu*/regs/identification, and that's the bulk of
> the useful information above

I'd like to come up with an extra CONFIG which parses:

arch/arm64/include/asm/cputype.h:

#define ARM_CPU_PART_AEM_V8             0xD0F
#define ARM_CPU_PART_FOUNDATION         0xD00
#define ARM_CPU_PART_CORTEX_A57         0xD07
#define ARM_CPU_PART_CORTEX_A72         0xD08

and

#define ARM_CPU_IMP_ARM                 0x41
#define ARM_CPU_IMP_APM                 0x50
#define ARM_CPU_IMP_CAVIUM              0x43
#define ARM_CPU_IMP_BRCM                0x42
#define ARM_CPU_IMP_QCOM                0x51
#define ARM_CPU_IMP_NVIDIA              0x4E

and converts the defines to strings, same as here:

arch/x86/include/asm/intel-family.h

#define INTEL_FAM6_SKYLAKE_L            0x4E
#define INTEL_FAM6_SKYLAKE              0x5E
#define INTEL_FAM6_SKYLAKE_X            0x55
#define INTEL_FAM6_KABYLAKE_L           0x8E
#define INTEL_FAM6_KABYLAKE             0x9E

and provide the model name (and for ARM the vendor name)
compiled in a module.

At least for aarch64 and x86 it seem to be possible
to get a vendor/model string from the same defined file:
/sys/devices/system/cpu/cpu0/info/{model_name,vendor}


> (aside from the flags/hwcaps).

which make sense to add there, right?

Thanks,

      Thomas




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[Mark Rutland]

On Fri, Dec 06, 2019 at 06:29:39PM +0100, Thomas Renninger wrote:
> On Friday, December 6, 2019 5:58:03 PM CET Mark Rutland wrote:
> > On Fri, Dec 06, 2019 at 05:24:18PM +0100, Thomas Renninger wrote:

> > For arm64 we already expose the MIDR and REVIDR register values under
> > /sys/devices/system/cpu/cpu*/regs/identification, and that's the bulk of
> > the useful information above
> 
> I'd like to come up with an extra CONFIG which parses:
> 
> arch/arm64/include/asm/cputype.h:
> 
> #define ARM_CPU_PART_AEM_V8             0xD0F
> #define ARM_CPU_PART_FOUNDATION         0xD00
> #define ARM_CPU_PART_CORTEX_A57         0xD07
> #define ARM_CPU_PART_CORTEX_A72         0xD08
> 
> and
> 
> #define ARM_CPU_IMP_ARM                 0x41
> #define ARM_CPU_IMP_APM                 0x50
> #define ARM_CPU_IMP_CAVIUM              0x43
> #define ARM_CPU_IMP_BRCM                0x42
> #define ARM_CPU_IMP_QCOM                0x51
> #define ARM_CPU_IMP_NVIDIA              0x4E
> 
> and converts the defines to strings, same as here:

A similar approach for /proc/cpuinfo has been NAK'd repeatedly in the
past. While some arguments against that don't apply here, I don't think
that we want to have to maintain an ever-growing list of strings that
end up being ABI which we cannot manage in a forwards-compatible manner.

When it is necessary to reliably and unambiguously identify a CPU, it'll
always end up being necessary to look at the MIDR (and possibly REVIDR),
so that's what applications should always do, and it's what users will
necessarily have to do when the kernel doesn't have a string for a CPU,
as is the case for all existing kernels.

I don't think that in-kernel stringification of the MIDR is a good idea,
and I would suggest not wasting your time on that.

Thanks,
Mark.

Re: [PATCH v5 0/3] sysfs: add sysfs based cpuinfo

[Mark Rutland]

On Fri, Dec 06, 2019 at 06:29:39PM +0100, Thomas Renninger wrote:
> On Friday, December 6, 2019 5:58:03 PM CET Mark Rutland wrote:
> > On Fri, Dec 06, 2019 at 05:24:18PM +0100, Thomas Renninger wrote:

> > For arm64 we already expose the MIDR and REVIDR register values under
> > /sys/devices/system/cpu/cpu*/regs/identification, and that's the bulk of
> > the useful information above
> 
> I'd like to come up with an extra CONFIG which parses:
> 
> arch/arm64/include/asm/cputype.h:
> 
> #define ARM_CPU_PART_AEM_V8             0xD0F
> #define ARM_CPU_PART_FOUNDATION         0xD00
> #define ARM_CPU_PART_CORTEX_A57         0xD07
> #define ARM_CPU_PART_CORTEX_A72         0xD08
> 
> and
> 
> #define ARM_CPU_IMP_ARM                 0x41
> #define ARM_CPU_IMP_APM                 0x50
> #define ARM_CPU_IMP_CAVIUM              0x43
> #define ARM_CPU_IMP_BRCM                0x42
> #define ARM_CPU_IMP_QCOM                0x51
> #define ARM_CPU_IMP_NVIDIA              0x4E
> 
> and converts the defines to strings, same as here:

A similar approach for /proc/cpuinfo has been NAK'd repeatedly in the
past. While some arguments against that don't apply here, I don't think
that we want to have to maintain an ever-growing list of strings that
end up being ABI which we cannot manage in a forwards-compatible manner.

When it is necessary to reliably and unambiguously identify a CPU, it'll
always end up being necessary to look at the MIDR (and possibly REVIDR),
so that's what applications should always do, and it's what users will
necessarily have to do when the kernel doesn't have a string for a CPU,
as is the case for all existing kernels.

I don't think that in-kernel stringification of the MIDR is a good idea,
and I would suggest not wasting your time on that.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Will Deacon]

On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> From: Felix Schnizlein <fschnizlein@suse.de>
> 
> Export all information from /proc/cpuinfo to sysfs:
> implementer, architecture, variant, part, revision,
> bogomips and flags are exported.
> 
> Example:
> /sys/devices/system/cpu/cpu1/info/:[0]# head *
> ==> architecture <==
> 8
> 
> ==> bogomips <==
> 40.00
> 
> ==> flags <==
> fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> 
> ==> implementer <==
> 0x51
> 
> ==> part <==
> 0xc00
> 
> ==> revision <==
> 1
> 
> ==> variant <==
> 0x0
> 
> Signed-off-by: Thomas Renninger <trenn@suse.de>
> Signed-off-by: Felix Schnizlein <fschnizlein@suse.com>
> ---
>  Documentation/ABI/testing/sysfs-devices-system-cpu | 22 +++++++++
>  arch/arm64/Kconfig                                 |  1 +
>  arch/arm64/kernel/cpuinfo.c                        | 55 ++++++++++++++++++++++
>  3 files changed, 78 insertions(+)

I don't understand why we need this on arm64 and why it's an improvement
over all the other schemes we already support for identifying CPU features.

Given the pain we've endured over the years exposing this sort of stuff to
userspace, I'm relucant to add more just for the fun of it.

Will

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Will Deacon]

On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> From: Felix Schnizlein <fschnizlein@suse.de>
> 
> Export all information from /proc/cpuinfo to sysfs:
> implementer, architecture, variant, part, revision,
> bogomips and flags are exported.
> 
> Example:
> /sys/devices/system/cpu/cpu1/info/:[0]# head *
> ==> architecture <==
> 8
> 
> ==> bogomips <==
> 40.00
> 
> ==> flags <==
> fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> 
> ==> implementer <==
> 0x51
> 
> ==> part <==
> 0xc00
> 
> ==> revision <==
> 1
> 
> ==> variant <==
> 0x0
> 
> Signed-off-by: Thomas Renninger <trenn@suse.de>
> Signed-off-by: Felix Schnizlein <fschnizlein@suse.com>
> ---
>  Documentation/ABI/testing/sysfs-devices-system-cpu | 22 +++++++++
>  arch/arm64/Kconfig                                 |  1 +
>  arch/arm64/kernel/cpuinfo.c                        | 55 ++++++++++++++++++++++
>  3 files changed, 78 insertions(+)

I don't understand why we need this on arm64 and why it's an improvement
over all the other schemes we already support for identifying CPU features.

Given the pain we've endured over the years exposing this sort of stuff to
userspace, I'm relucant to add more just for the fun of it.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Thomas Renninger]

On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > From: Felix Schnizlein <fschnizlein@suse.de>
> > 
> > Export all information from /proc/cpuinfo to sysfs:
> > implementer, architecture, variant, part, revision,
> > bogomips and flags are exported.
> > 
> > Example:
> > /sys/devices/system/cpu/cpu1/info/:[0]# head *

...

> > ==> flags <==
> > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
 
...

> I don't understand why we need this on arm64

The first intention of these patches is to port x86 /proc/cpuinfo.

Because of the divergence of /proc/cpuinfo and the totally different
info exported there across architectures,
therefore it is also tried to get a unified interface across architectures 
where possible.

So for flags and bugs this may work out, right?

For the rest, it looks like people again only had their CPU in mind and
exported to userspace what currently was needed...

> and why it's an improvement
> over all the other schemes we already support for identifying CPU features.

Sigh...

> Given the pain we've endured over the years exposing this sort of stuff to
> userspace, I'm relucant to add more just for the fun of it.

If there should ever be something like a string describing the CPU...
In x86 it comes from the CPU itself.
Maybe we get a model description at some point as well...

Or any other entity which may also get exported on other archs..

Please remember this interface and watch out whether you could export
things under the same name as done on other architectures.

I'll revert everything but flags for ARM now.
But this is the best example for the need of a generic interface:

x86 -   /proc/cpuinfo:
flags           : ...
arm64 - /proc/cpuinfo:
Features        : ...

even it is exactly the same kernel interface, even x86 flags are used 
according to arch/arm64/include/asm/cpufeature.h:

  * We use arm64_cpu_capabilities to represent system features, errata work

But it is named differently in /proc/cpuinfo.
This should not happen again in /sys/...

    Thomas

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Thomas Renninger]

On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > From: Felix Schnizlein <fschnizlein@suse.de>
> > 
> > Export all information from /proc/cpuinfo to sysfs:
> > implementer, architecture, variant, part, revision,
> > bogomips and flags are exported.
> > 
> > Example:
> > /sys/devices/system/cpu/cpu1/info/:[0]# head *

...

> > ==> flags <==
> > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
 
...

> I don't understand why we need this on arm64

The first intention of these patches is to port x86 /proc/cpuinfo.

Because of the divergence of /proc/cpuinfo and the totally different
info exported there across architectures,
therefore it is also tried to get a unified interface across architectures 
where possible.

So for flags and bugs this may work out, right?

For the rest, it looks like people again only had their CPU in mind and
exported to userspace what currently was needed...

> and why it's an improvement
> over all the other schemes we already support for identifying CPU features.

Sigh...

> Given the pain we've endured over the years exposing this sort of stuff to
> userspace, I'm relucant to add more just for the fun of it.

If there should ever be something like a string describing the CPU...
In x86 it comes from the CPU itself.
Maybe we get a model description at some point as well...

Or any other entity which may also get exported on other archs..

Please remember this interface and watch out whether you could export
things under the same name as done on other architectures.

I'll revert everything but flags for ARM now.
But this is the best example for the need of a generic interface:

x86 -   /proc/cpuinfo:
flags           : ...
arm64 - /proc/cpuinfo:
Features        : ...

even it is exactly the same kernel interface, even x86 flags are used 
according to arch/arm64/include/asm/cpufeature.h:

  * We use arm64_cpu_capabilities to represent system features, errata work

But it is named differently in /proc/cpuinfo.
This should not happen again in /sys/...

    Thomas



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Will Deacon]

On Mon, Dec 09, 2019 at 12:28:44PM +0100, Thomas Renninger wrote:
> On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > > From: Felix Schnizlein <fschnizlein@suse.de>
> > > 
> > > Export all information from /proc/cpuinfo to sysfs:
> > > implementer, architecture, variant, part, revision,
> > > bogomips and flags are exported.
> > > 
> > > Example:
> > > /sys/devices/system/cpu/cpu1/info/:[0]# head *
> 
> ...
> 
> > > ==> flags <==
> > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
>  
> ...
> 
> > I don't understand why we need this on arm64
> 
> The first intention of these patches is to port x86 /proc/cpuinfo.

That doesn't answer my question. Why do we want a port of x86 /proc/cpuinfo
on arm64? Or do you mean something else?

> Because of the divergence of /proc/cpuinfo and the totally different
> info exported there across architectures,
> therefore it is also tried to get a unified interface across architectures 
> where possible.

But as you say, the information is totally different, so I think the scope
for a unified interface is somewhat questionable. Can you give some examples
of when a piece of architecture-agnostic software can sensibly benefit from
this interface in a way that couldn't be achieved already using a userspace
library, please?

> So for flags and bugs this may work out, right?

We don't have a 'bugs' entry on arm64, so I don't understand why you're
mentioning that as an example of something that works well here. The flags
thing is a set of architecture-specific strings, so why is having a common
interface at all useful there? Even if we exposed them via sysfs, existing
software will continue to grep them out of /proc/cpuinfo because it's more
reliable and new software would still be encouraged to use either the HWCAPs
directly or, even better, our CPUID (MRS) emulation.

> For the rest, it looks like people again only had their CPU in mind and
> exported to userspace what currently was needed...

Cool story: we tried to tidy up our /proc/cpuinfo format for arm64 because
we were aware that it was an ABI nightmare that wasn't fully understood, so
we played it very cautiously. Unfortunately, it turned out that real
applications got in the way and we basically had to follow an arm32-like
format to avoid breaking userspace. But it is what it is and I don't really
fancy exposing more stuff without decent rationale...

> > and why it's an improvement
> > over all the other schemes we already support for identifying CPU features.
> 
> Sigh...

... which this isn't. :/

> > Given the pain we've endured over the years exposing this sort of stuff to
> > userspace, I'm relucant to add more just for the fun of it.
> 
> If there should ever be something like a string describing the CPU...
> In x86 it comes from the CPU itself.
> Maybe we get a model description at some point as well...
> 
> Or any other entity which may also get exported on other archs..

Not sure who this is aimed at tbh.

> Please remember this interface and watch out whether you could export
> things under the same name as done on other architectures.
> 
> I'll revert everything but flags for ARM now.

Please revert the whole lot for arm64, I don't even want to see the iCPU
feature flags exposed like this without a good justification.

> But this is the best example for the need of a generic interface:
> 
> x86 -   /proc/cpuinfo:
> flags           : ...
> arm64 - /proc/cpuinfo:
> Features        : ...
> 
> even it is exactly the same kernel interface, even x86 flags are used 
> according to arch/arm64/include/asm/cpufeature.h:
> 
>   * We use arm64_cpu_capabilities to represent system features, errata work
> 
> But it is named differently in /proc/cpuinfo.

As I said earlier, that's the least of your worries. The *contents of the
string* is entirely different based on the architecture. Here's a quiz
for you:

	arm32 Feature    arm64 Feature    x86 flag    Same thing?
	"vfp"            "fp"		  "fpu"
	"idivt"          "cpuid"          "cpuid"
	"edsp"           "sve2"           "sse2"
        "aes"            "ssbs"           "ssbd"
        "swp"            "sb"             "ss"

So it's all well and good having everybody call these either "Features"
or "flags", but I think you're missing the real issue which is that the
values themselves are meaningless without architecture-specific knowledge,
at which point you can parse /proc/cpuinfo accordingly.

Unless I missed it, you also don't seem to handle compat tasks at all in
your patch.

> This should not happen again in /sys/...

I wish I could believe you.

Will

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Will Deacon]

On Mon, Dec 09, 2019 at 12:28:44PM +0100, Thomas Renninger wrote:
> On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > > From: Felix Schnizlein <fschnizlein@suse.de>
> > > 
> > > Export all information from /proc/cpuinfo to sysfs:
> > > implementer, architecture, variant, part, revision,
> > > bogomips and flags are exported.
> > > 
> > > Example:
> > > /sys/devices/system/cpu/cpu1/info/:[0]# head *
> 
> ...
> 
> > > ==> flags <==
> > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
>  
> ...
> 
> > I don't understand why we need this on arm64
> 
> The first intention of these patches is to port x86 /proc/cpuinfo.

That doesn't answer my question. Why do we want a port of x86 /proc/cpuinfo
on arm64? Or do you mean something else?

> Because of the divergence of /proc/cpuinfo and the totally different
> info exported there across architectures,
> therefore it is also tried to get a unified interface across architectures 
> where possible.

But as you say, the information is totally different, so I think the scope
for a unified interface is somewhat questionable. Can you give some examples
of when a piece of architecture-agnostic software can sensibly benefit from
this interface in a way that couldn't be achieved already using a userspace
library, please?

> So for flags and bugs this may work out, right?

We don't have a 'bugs' entry on arm64, so I don't understand why you're
mentioning that as an example of something that works well here. The flags
thing is a set of architecture-specific strings, so why is having a common
interface at all useful there? Even if we exposed them via sysfs, existing
software will continue to grep them out of /proc/cpuinfo because it's more
reliable and new software would still be encouraged to use either the HWCAPs
directly or, even better, our CPUID (MRS) emulation.

> For the rest, it looks like people again only had their CPU in mind and
> exported to userspace what currently was needed...

Cool story: we tried to tidy up our /proc/cpuinfo format for arm64 because
we were aware that it was an ABI nightmare that wasn't fully understood, so
we played it very cautiously. Unfortunately, it turned out that real
applications got in the way and we basically had to follow an arm32-like
format to avoid breaking userspace. But it is what it is and I don't really
fancy exposing more stuff without decent rationale...

> > and why it's an improvement
> > over all the other schemes we already support for identifying CPU features.
> 
> Sigh...

... which this isn't. :/

> > Given the pain we've endured over the years exposing this sort of stuff to
> > userspace, I'm relucant to add more just for the fun of it.
> 
> If there should ever be something like a string describing the CPU...
> In x86 it comes from the CPU itself.
> Maybe we get a model description at some point as well...
> 
> Or any other entity which may also get exported on other archs..

Not sure who this is aimed at tbh.

> Please remember this interface and watch out whether you could export
> things under the same name as done on other architectures.
> 
> I'll revert everything but flags for ARM now.

Please revert the whole lot for arm64, I don't even want to see the iCPU
feature flags exposed like this without a good justification.

> But this is the best example for the need of a generic interface:
> 
> x86 -   /proc/cpuinfo:
> flags           : ...
> arm64 - /proc/cpuinfo:
> Features        : ...
> 
> even it is exactly the same kernel interface, even x86 flags are used 
> according to arch/arm64/include/asm/cpufeature.h:
> 
>   * We use arm64_cpu_capabilities to represent system features, errata work
> 
> But it is named differently in /proc/cpuinfo.

As I said earlier, that's the least of your worries. The *contents of the
string* is entirely different based on the architecture. Here's a quiz
for you:

	arm32 Feature    arm64 Feature    x86 flag    Same thing?
	"vfp"            "fp"		  "fpu"
	"idivt"          "cpuid"          "cpuid"
	"edsp"           "sve2"           "sse2"
        "aes"            "ssbs"           "ssbd"
        "swp"            "sb"             "ss"

So it's all well and good having everybody call these either "Features"
or "flags", but I think you're missing the real issue which is that the
values themselves are meaningless without architecture-specific knowledge,
at which point you can parse /proc/cpuinfo accordingly.

Unless I missed it, you also don't seem to handle compat tasks at all in
your patch.

> This should not happen again in /sys/...

I wish I could believe you.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Thomas Renninger]

On Monday, December 9, 2019 6:38:05 PM CET Will Deacon wrote:
> On Mon, Dec 09, 2019 at 12:28:44PM +0100, Thomas Renninger wrote:
> > On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> > > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > > > From: Felix Schnizlein <fschnizlein@suse.de>
> > > > 
> > > > Export all information from /proc/cpuinfo to sysfs:
> > > > implementer, architecture, variant, part, revision,
> > > > bogomips and flags are exported.
> > > > 
> > > > Example:
> > > > /sys/devices/system/cpu/cpu1/info/:[0]# head *
> > 
> > ...
> > 
> > > > ==> flags <==
> > > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> > 
> > ...
> > 
> > > I don't understand why we need this on arm64

Again: proc is moving to sys.
You probably export feature flags in /proc/cpuinfo for a good reason.
So where in sysfs should this show up?

> Even if we exposed them via sysfs, existing
> software will continue to grep them out of /proc/cpuinfo because it's more
> reliable and new software would still be encouraged to use either the HWCAPs
> directly or, even better, our CPUID (MRS) emulation.

Ok, so /proc/cpuinfo
Features:

is deprecated on arm64. Is that correct?
Then it would indeed not make sense to port it/anything to sys.
 
It is this comment you are referring to:

arch/arm64/kernel/cpuinfo.c
                 * Dump out the common processor features in a single line.
                 * Userspace should read the hwcaps with getauxval(AT_HWCAP)
                 * rather than attempting to parse this, but there's a body of
                 * software which does already (at least for 32-bit).

Then let's shorten this.
Sorry for keep digging/asking.

Felix made this up rather neat, so that other archs can implement to expose 
sysfs CPU info easy and consistent.
While x86 also ported parts of cpuinfo, e.g. microcode version, most general
info is still missing in sysfs.

If I find the time, I may check for other archs like ppc64le or s390x to find
data which still should show up in sysfs and could then be put in the same
directory/file structure.

ARM people may still want to make use of this at some point of time, if 
appropriate. I'll drop patch 3/3.

Thanks for explaining me the ARM details,

   Thomas

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Thomas Renninger]

On Monday, December 9, 2019 6:38:05 PM CET Will Deacon wrote:
> On Mon, Dec 09, 2019 at 12:28:44PM +0100, Thomas Renninger wrote:
> > On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> > > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > > > From: Felix Schnizlein <fschnizlein@suse.de>
> > > > 
> > > > Export all information from /proc/cpuinfo to sysfs:
> > > > implementer, architecture, variant, part, revision,
> > > > bogomips and flags are exported.
> > > > 
> > > > Example:
> > > > /sys/devices/system/cpu/cpu1/info/:[0]# head *
> > 
> > ...
> > 
> > > > ==> flags <==
> > > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> > 
> > ...
> > 
> > > I don't understand why we need this on arm64

Again: proc is moving to sys.
You probably export feature flags in /proc/cpuinfo for a good reason.
So where in sysfs should this show up?

> Even if we exposed them via sysfs, existing
> software will continue to grep them out of /proc/cpuinfo because it's more
> reliable and new software would still be encouraged to use either the HWCAPs
> directly or, even better, our CPUID (MRS) emulation.

Ok, so /proc/cpuinfo
Features:

is deprecated on arm64. Is that correct?
Then it would indeed not make sense to port it/anything to sys.
 
It is this comment you are referring to:

arch/arm64/kernel/cpuinfo.c
                 * Dump out the common processor features in a single line.
                 * Userspace should read the hwcaps with getauxval(AT_HWCAP)
                 * rather than attempting to parse this, but there's a body of
                 * software which does already (at least for 32-bit).

Then let's shorten this.
Sorry for keep digging/asking.

Felix made this up rather neat, so that other archs can implement to expose 
sysfs CPU info easy and consistent.
While x86 also ported parts of cpuinfo, e.g. microcode version, most general
info is still missing in sysfs.

If I find the time, I may check for other archs like ppc64le or s390x to find
data which still should show up in sysfs and could then be put in the same
directory/file structure.

ARM people may still want to make use of this at some point of time, if 
appropriate. I'll drop patch 3/3.

Thanks for explaining me the ARM details,

   Thomas



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Greg KH]

On Tue, Dec 10, 2019 at 02:33:07PM +0100, Thomas Renninger wrote:
> On Monday, December 9, 2019 6:38:05 PM CET Will Deacon wrote:
> > On Mon, Dec 09, 2019 at 12:28:44PM +0100, Thomas Renninger wrote:
> > > On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> > > > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > > > > From: Felix Schnizlein <fschnizlein@suse.de>
> > > > > 
> > > > > Export all information from /proc/cpuinfo to sysfs:
> > > > > implementer, architecture, variant, part, revision,
> > > > > bogomips and flags are exported.
> > > > > 
> > > > > Example:
> > > > > /sys/devices/system/cpu/cpu1/info/:[0]# head *
> > > 
> > > ...
> > > 
> > > > > ==> flags <==
> > > > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> > > 
> > > ...
> > > 
> > > > I don't understand why we need this on arm64
> 
> Again: proc is moving to sys.

No.  New stuff is to be added to /sys/, don't add new things to /proc
unless it deals with processes.

There is no mass-migration of existing /proc files to sysfs for no good
reason.

> You probably export feature flags in /proc/cpuinfo for a good reason.
> So where in sysfs should this show up?

Why does it have to live in sysfs if it is already in /proc and parsed
properly by tools?

thanks,

greg k-h

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Greg KH]

On Tue, Dec 10, 2019 at 02:33:07PM +0100, Thomas Renninger wrote:
> On Monday, December 9, 2019 6:38:05 PM CET Will Deacon wrote:
> > On Mon, Dec 09, 2019 at 12:28:44PM +0100, Thomas Renninger wrote:
> > > On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> > > > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > > > > From: Felix Schnizlein <fschnizlein@suse.de>
> > > > > 
> > > > > Export all information from /proc/cpuinfo to sysfs:
> > > > > implementer, architecture, variant, part, revision,
> > > > > bogomips and flags are exported.
> > > > > 
> > > > > Example:
> > > > > /sys/devices/system/cpu/cpu1/info/:[0]# head *
> > > 
> > > ...
> > > 
> > > > > ==> flags <==
> > > > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> > > 
> > > ...
> > > 
> > > > I don't understand why we need this on arm64
> 
> Again: proc is moving to sys.

No.  New stuff is to be added to /sys/, don't add new things to /proc
unless it deals with processes.

There is no mass-migration of existing /proc files to sysfs for no good
reason.

> You probably export feature flags in /proc/cpuinfo for a good reason.
> So where in sysfs should this show up?

Why does it have to live in sysfs if it is already in /proc and parsed
properly by tools?

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Thomas Renninger]

On Tuesday, December 10, 2019 3:47:37 PM CET Greg KH wrote:
> On Tue, Dec 10, 2019 at 02:33:07PM +0100, Thomas Renninger wrote:
> > On Monday, December 9, 2019 6:38:05 PM CET Will Deacon wrote:
> > > On Mon, Dec 09, 2019 at 12:28:44PM +0100, Thomas Renninger wrote:
> > > > On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> > > > > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > > > > > From: Felix Schnizlein <fschnizlein@suse.de>
> > > > > > 
> > > > > > Export all information from /proc/cpuinfo to sysfs:
> > > > > > implementer, architecture, variant, part, revision,
> > > > > > bogomips and flags are exported.
> > > > > > 
> > > > > > Example:
> > > > > > /sys/devices/system/cpu/cpu1/info/:[0]# head *
> > > > 
> > > > ...
> > > > 
> > > > > > ==> flags <==
> > > > > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> > > > 
> > > > ...
> > > > 
> > > > > I don't understand why we need this on arm64
> > 
> > Again: proc is moving to sys.
> 
> No.  New stuff is to be added to /sys/, don't add new things to /proc
> unless it deals with processes.
> 
> There is no mass-migration of existing /proc files to sysfs for no good
> reason.
> 
> > You probably export feature flags in /proc/cpuinfo for a good reason.
> > So where in sysfs should this show up?
> 
> Why does it have to live in sysfs if it is already in /proc and parsed
> properly by tools?

Parsing /proc/cpuinfo is the best example why we have sysfs...
Most important things have already been ported:

microcode       : 0x10
cat /sys/devices/system/cpu/cpu1/microcode/version
0x10

physical id     : 0
siblings        : 8
core id         : 1
cpu cores       : 4
...
/sys/devices/system/cpu/cpu1/topology/

clflush size    : 64
cache_alignment : 64
...
/sys/devices/system/cpu/cpu1/cache/


Only missing important info which still is needed is family/model/stepping, 
name, bugs and flags
cpufreq also got ported to sysfs quite some time ago already.

I am aware that /proc/cpuinfo won't vanish...
...the next decade. Still I am confident I will still see this.

Still relevant info which is accessed by (newly written) userspace tools 
should read out info via sysfs.

Beside microcode, topology, cache, cpufreq,...
info, there now is also family, model, stepping, bugs, flags and name

There rest is (from my perspective) really old ugly stuff and not needed 
anymore by recent tools.


   Thomas

Re: [PATCH 3/3] arm64 cpuinfo: implement sysfs nodes for arm64

[Thomas Renninger]

On Tuesday, December 10, 2019 3:47:37 PM CET Greg KH wrote:
> On Tue, Dec 10, 2019 at 02:33:07PM +0100, Thomas Renninger wrote:
> > On Monday, December 9, 2019 6:38:05 PM CET Will Deacon wrote:
> > > On Mon, Dec 09, 2019 at 12:28:44PM +0100, Thomas Renninger wrote:
> > > > On Monday, December 9, 2019 11:31:11 AM CET Will Deacon wrote:
> > > > > On Fri, Dec 06, 2019 at 05:24:21PM +0100, Thomas Renninger wrote:
> > > > > > From: Felix Schnizlein <fschnizlein@suse.de>
> > > > > > 
> > > > > > Export all information from /proc/cpuinfo to sysfs:
> > > > > > implementer, architecture, variant, part, revision,
> > > > > > bogomips and flags are exported.
> > > > > > 
> > > > > > Example:
> > > > > > /sys/devices/system/cpu/cpu1/info/:[0]# head *
> > > > 
> > > > ...
> > > > 
> > > > > > ==> flags <==
> > > > > > fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
> > > > 
> > > > ...
> > > > 
> > > > > I don't understand why we need this on arm64
> > 
> > Again: proc is moving to sys.
> 
> No.  New stuff is to be added to /sys/, don't add new things to /proc
> unless it deals with processes.
> 
> There is no mass-migration of existing /proc files to sysfs for no good
> reason.
> 
> > You probably export feature flags in /proc/cpuinfo for a good reason.
> > So where in sysfs should this show up?
> 
> Why does it have to live in sysfs if it is already in /proc and parsed
> properly by tools?

Parsing /proc/cpuinfo is the best example why we have sysfs...
Most important things have already been ported:

microcode       : 0x10
cat /sys/devices/system/cpu/cpu1/microcode/version
0x10

physical id     : 0
siblings        : 8
core id         : 1
cpu cores       : 4
...
/sys/devices/system/cpu/cpu1/topology/

clflush size    : 64
cache_alignment : 64
...
/sys/devices/system/cpu/cpu1/cache/


Only missing important info which still is needed is family/model/stepping, 
name, bugs and flags
cpufreq also got ported to sysfs quite some time ago already.

I am aware that /proc/cpuinfo won't vanish...
...the next decade. Still I am confident I will still see this.

Still relevant info which is accessed by (newly written) userspace tools 
should read out info via sysfs.

Beside microcode, topology, cache, cpufreq,...
info, there now is also family, model, stepping, bugs, flags and name

There rest is (from my perspective) really old ugly stuff and not needed 
anymore by recent tools.


   Thomas



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Gleixner]

Greg KH <gregkh@linuxfoundation.org> writes:
> On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
>> From: Felix Schnizlein <fschnizlein@suse.de>
>> ==> flags <==
>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip
>
> One file with all of that?  We are going to run into problems
> eventually, that should be split up.
>
> Just like bugs, that's going to just grow over time and eventually
> overflow PAGE_SIZE :(
>
> Make this:
>   ├── flags
>   │   ├── fpu
>   │   ├── vme
> ...
>
> Much simpler to parse, right?

Well, I'm not really sure whether 100+ files are simpler to parse.

Aside of that I really don't see the value for 100+ files per CPU which
are just returning 1 or True or whatever as long as you are not
suggesting to provide real feature files which have 0/1 or True/False
content.

But I still don't get the whole thing. The only "argument" I've seen so
far is the 'proc moves to sys' mantra, but that does not make it any
better.

We won't get rid of /proc/cpuinfo for a very long time simply because
too much userspace uses it. Introducing a mess in /sys/ in parallel just
for following the mantra does not help much.

Also IF we ever expose feature flags in sys then this needs to be a
split ino

  cpu/common_features

and

  cpu/CPU$N/unique_features

On most systems unique_features wont exist, but there is such stuff on
the horizon.

Thanks,

        tglx

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Gleixner]

Greg KH <gregkh@linuxfoundation.org> writes:
> On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
>> From: Felix Schnizlein <fschnizlein@suse.de>
>> ==> flags <==
>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip
>
> One file with all of that?  We are going to run into problems
> eventually, that should be split up.
>
> Just like bugs, that's going to just grow over time and eventually
> overflow PAGE_SIZE :(
>
> Make this:
>   ├── flags
>   │   ├── fpu
>   │   ├── vme
> ...
>
> Much simpler to parse, right?

Well, I'm not really sure whether 100+ files are simpler to parse.

Aside of that I really don't see the value for 100+ files per CPU which
are just returning 1 or True or whatever as long as you are not
suggesting to provide real feature files which have 0/1 or True/False
content.

But I still don't get the whole thing. The only "argument" I've seen so
far is the 'proc moves to sys' mantra, but that does not make it any
better.

We won't get rid of /proc/cpuinfo for a very long time simply because
too much userspace uses it. Introducing a mess in /sys/ in parallel just
for following the mantra does not help much.

Also IF we ever expose feature flags in sys then this needs to be a
split ino

  cpu/common_features

and

  cpu/CPU$N/unique_features

On most systems unique_features wont exist, but there is such stuff on
the horizon.

Thanks,

        tglx

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Tue, Dec 10, 2019 at 09:48:54PM +0100, Thomas Gleixner wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> > On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
> >> From: Felix Schnizlein <fschnizlein@suse.de>
> >> ==> flags <==
> >> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip
> >
> > One file with all of that?  We are going to run into problems
> > eventually, that should be split up.
> >
> > Just like bugs, that's going to just grow over time and eventually
> > overflow PAGE_SIZE :(
> >
> > Make this:
> >   ├── flags
> >   │   ├── fpu
> >   │   ├── vme
> > ...
> >
> > Much simpler to parse, right?
> 
> Well, I'm not really sure whether 100+ files are simpler to parse.
> 
> Aside of that I really don't see the value for 100+ files per CPU which
> are just returning 1 or True or whatever as long as you are not
> suggesting to provide real feature files which have 0/1 or True/False
> content.
> 
> But I still don't get the whole thing. The only "argument" I've seen so
> far is the 'proc moves to sys' mantra, but that does not make it any
> better.

That is not a valid mantra, as I tried to explain later in this thread.

I don't understand the need for this patchset either, all I was trying
to do was to at least make it sane from a sysfs-point-of-view if people
really wanted to do this type of thing.

> We won't get rid of /proc/cpuinfo for a very long time simply because
> too much userspace uses it. Introducing a mess in /sys/ in parallel just
> for following the mantra does not help much.

Again, invalid mantra, not a valid reason :)

I think this is a patchset in search of a problem, which is why it was
dropped all those years ago...

thanks,

greg k-h

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Tue, Dec 10, 2019 at 09:48:54PM +0100, Thomas Gleixner wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> > On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
> >> From: Felix Schnizlein <fschnizlein@suse.de>
> >> ==> flags <==
> >> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat umip
> >
> > One file with all of that?  We are going to run into problems
> > eventually, that should be split up.
> >
> > Just like bugs, that's going to just grow over time and eventually
> > overflow PAGE_SIZE :(
> >
> > Make this:
> >   ├── flags
> >   │   ├── fpu
> >   │   ├── vme
> > ...
> >
> > Much simpler to parse, right?
> 
> Well, I'm not really sure whether 100+ files are simpler to parse.
> 
> Aside of that I really don't see the value for 100+ files per CPU which
> are just returning 1 or True or whatever as long as you are not
> suggesting to provide real feature files which have 0/1 or True/False
> content.
> 
> But I still don't get the whole thing. The only "argument" I've seen so
> far is the 'proc moves to sys' mantra, but that does not make it any
> better.

That is not a valid mantra, as I tried to explain later in this thread.

I don't understand the need for this patchset either, all I was trying
to do was to at least make it sane from a sysfs-point-of-view if people
really wanted to do this type of thing.

> We won't get rid of /proc/cpuinfo for a very long time simply because
> too much userspace uses it. Introducing a mess in /sys/ in parallel just
> for following the mantra does not help much.

Again, invalid mantra, not a valid reason :)

I think this is a patchset in search of a problem, which is why it was
dropped all those years ago...

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Renninger]

On Tuesday, December 10, 2019 9:48:54 PM CET Thomas Gleixner wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> > On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
> >> From: Felix Schnizlein <fschnizlein@suse.de>
> >> ==> flags <==
> >> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
> >> clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc
> >> rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma
> >> cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave
> >> avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti
> >> ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
> >> xsaveopt arat umip> 
> > One file with all of that?  We are going to run into problems
> > eventually, that should be split up.
> > 
> > Just like bugs, that's going to just grow over time and eventually
> > overflow PAGE_SIZE :(
> > 
> > Make this:
> >   ├── flags
> >   │   ├── fpu
> >   │   ├── vme
> > 
> > ...
> > 
> > Much simpler to parse, right?
> 
> Well, I'm not really sure whether 100+ files are simpler to parse.
> 
> Aside of that I really don't see the value for 100+ files per CPU which
> are just returning 1 or True or whatever as long as you are not
> suggesting to provide real feature files which have 0/1 or True/False
> content.

I also do not like the one file per cpu flag approach.
This still is one "data"/"info" per sysfs file.
Similar to:
cpu/cpufreq/policy1/scaling_available_governors
and probably a lot others. If PAGE_SIZE overflow has to be cared for, then be 
it.
 
> But I still don't get the whole thing. The only "argument" I've seen so
> far is the 'proc moves to sys' mantra, but that does not make it any
> better.
> 
> We won't get rid of /proc/cpuinfo for a very long time simply because
> too much userspace uses it.

The reason we will never get rid of it is:
Newly written userspace tools still (have to) make use it.
This is because of a small set of remaining info which is convenient
to have in userspace but which is not avail in sysfs yet.

Therefore only x of the 26 /proc/cpuinfo data has been picked up.

For decades unused info like:
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
power management:

shall die at (long but) some point of time.

It's quite some years ago when acpi and cpufreq proc info first got
deprecated and duplicated in sys.
It has been said that it needs years of deprecation that the event file
on which damons were listening for acpi events can ever be removed...
It has been 2013 when the removal has been done, more than 5 years ago:
1696d9dc57e062ce5200f6a42a6aaada15b434bb
ACPI: Remove the old /proc/acpi/event interface

/proc/cpuinfo may need some years more, but there should be no
reason it is still getting used.

> Introducing a mess in /sys/ in parallel just
> for following the mantra does not help much.
 
> Also IF we ever expose feature flags in sys then this needs to be a
> split ino
> 
>   cpu/common_features
> 
> and
> 
>   cpu/CPU$N/unique_features

Makes sense.
feature (without common/unique) is also a better naming than flags.

If Greg (and others) are ok, I would add "page size exceeding" handling.
Hm, quick searching for an example I realize that debugfs can exceed page 
size. Is it that hard to expose a sysfs file larger than page size?

> On most systems unique_features wont exist, but there is such stuff on
> the horizon.

I still wait a bit before doing work for nothing.
I hope everybody agrees, that remaining useful info in /proc/cpuinfo should
show up in /sys if that did not happen yet. And that userspace tools should
not (need to) make use of /proc/cpuinfo anymore.

    Thomas

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Renninger]

On Tuesday, December 10, 2019 9:48:54 PM CET Thomas Gleixner wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> > On Fri, Dec 06, 2019 at 05:24:20PM +0100, Thomas Renninger wrote:
> >> From: Felix Schnizlein <fschnizlein@suse.de>
> >> ==> flags <==
> >> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
> >> clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc
> >> rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma
> >> cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave
> >> avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti
> >> ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
> >> xsaveopt arat umip> 
> > One file with all of that?  We are going to run into problems
> > eventually, that should be split up.
> > 
> > Just like bugs, that's going to just grow over time and eventually
> > overflow PAGE_SIZE :(
> > 
> > Make this:
> >   ├── flags
> >   │   ├── fpu
> >   │   ├── vme
> > 
> > ...
> > 
> > Much simpler to parse, right?
> 
> Well, I'm not really sure whether 100+ files are simpler to parse.
> 
> Aside of that I really don't see the value for 100+ files per CPU which
> are just returning 1 or True or whatever as long as you are not
> suggesting to provide real feature files which have 0/1 or True/False
> content.

I also do not like the one file per cpu flag approach.
This still is one "data"/"info" per sysfs file.
Similar to:
cpu/cpufreq/policy1/scaling_available_governors
and probably a lot others. If PAGE_SIZE overflow has to be cared for, then be 
it.
 
> But I still don't get the whole thing. The only "argument" I've seen so
> far is the 'proc moves to sys' mantra, but that does not make it any
> better.
> 
> We won't get rid of /proc/cpuinfo for a very long time simply because
> too much userspace uses it.

The reason we will never get rid of it is:
Newly written userspace tools still (have to) make use it.
This is because of a small set of remaining info which is convenient
to have in userspace but which is not avail in sysfs yet.

Therefore only x of the 26 /proc/cpuinfo data has been picked up.

For decades unused info like:
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
power management:

shall die at (long but) some point of time.

It's quite some years ago when acpi and cpufreq proc info first got
deprecated and duplicated in sys.
It has been said that it needs years of deprecation that the event file
on which damons were listening for acpi events can ever be removed...
It has been 2013 when the removal has been done, more than 5 years ago:
1696d9dc57e062ce5200f6a42a6aaada15b434bb
ACPI: Remove the old /proc/acpi/event interface

/proc/cpuinfo may need some years more, but there should be no
reason it is still getting used.

> Introducing a mess in /sys/ in parallel just
> for following the mantra does not help much.
 
> Also IF we ever expose feature flags in sys then this needs to be a
> split ino
> 
>   cpu/common_features
> 
> and
> 
>   cpu/CPU$N/unique_features

Makes sense.
feature (without common/unique) is also a better naming than flags.

If Greg (and others) are ok, I would add "page size exceeding" handling.
Hm, quick searching for an example I realize that debugfs can exceed page 
size. Is it that hard to expose a sysfs file larger than page size?

> On most systems unique_features wont exist, but there is such stuff on
> the horizon.

I still wait a bit before doing work for nothing.
I hope everybody agrees, that remaining useful info in /proc/cpuinfo should
show up in /sys if that did not happen yet. And that userspace tools should
not (need to) make use of /proc/cpuinfo anymore.

    Thomas



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:
> If Greg (and others) are ok, I would add "page size exceeding" handling.
> Hm, quick searching for an example I realize that debugfs can exceed page 
> size. Is it that hard to expose a sysfs file larger than page size?

No, there is a simple way to do it, but I'm not going to show you how as
it is NOT how to use sysfs at all :)

Why are you wanting to dump this whole mess into one file and then parse
it, it's no different from having 100+ different sysfs files and then
doing a readdir(3) on the thing, right?

greg k-h

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:
> If Greg (and others) are ok, I would add "page size exceeding" handling.
> Hm, quick searching for an example I realize that debugfs can exceed page 
> size. Is it that hard to expose a sysfs file larger than page size?

No, there is a simple way to do it, but I'm not going to show you how as
it is NOT how to use sysfs at all :)

Why are you wanting to dump this whole mess into one file and then parse
it, it's no different from having 100+ different sysfs files and then
doing a readdir(3) on the thing, right?

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Renninger]

On Wednesday, December 11, 2019 2:56:19 PM CET Greg KH wrote:
> On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:
> > If Greg (and others) are ok, I would add "page size exceeding" handling.
> > Hm, quick searching for an example I realize that debugfs can exceed page
> > size. Is it that hard to expose a sysfs file larger than page size?
> 
> No, there is a simple way to do it, but I'm not going to show you how as
> it is NOT how to use sysfs at all :)
>
> Why are you wanting to dump this whole mess into one file

I wouldn't call a whitespace separated list of CPU feature flags a mess...

> and then parse
> it, it's no different from having 100+ different sysfs files and then
> doing a readdir(3) on the thing, right?

If this is the way it "has to"/should/"is designed for" to export such
(not that complex) data via sysfs...

I do not have such a strong opinion on the how, this is up to maintainers
to discuss.

I hope it is agreed that this info is worth exporting via sysfs.
So I wait for the "how are CPU feature flags/bugs data" to be exported
via sysfs and I volunteer to pick it up and submit a patch out of it.

Thanks,

   Thomas

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Renninger]

On Wednesday, December 11, 2019 2:56:19 PM CET Greg KH wrote:
> On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:
> > If Greg (and others) are ok, I would add "page size exceeding" handling.
> > Hm, quick searching for an example I realize that debugfs can exceed page
> > size. Is it that hard to expose a sysfs file larger than page size?
> 
> No, there is a simple way to do it, but I'm not going to show you how as
> it is NOT how to use sysfs at all :)
>
> Why are you wanting to dump this whole mess into one file

I wouldn't call a whitespace separated list of CPU feature flags a mess...

> and then parse
> it, it's no different from having 100+ different sysfs files and then
> doing a readdir(3) on the thing, right?

If this is the way it "has to"/should/"is designed for" to export such
(not that complex) data via sysfs...

I do not have such a strong opinion on the how, this is up to maintainers
to discuss.

I hope it is agreed that this info is worth exporting via sysfs.
So I wait for the "how are CPU feature flags/bugs data" to be exported
via sysfs and I volunteer to pick it up and submit a patch out of it.

Thanks,

   Thomas



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Wed, Dec 11, 2019 at 03:12:51PM +0100, Thomas Renninger wrote:
> On Wednesday, December 11, 2019 2:56:19 PM CET Greg KH wrote:
> > On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:
> > > If Greg (and others) are ok, I would add "page size exceeding" handling.
> > > Hm, quick searching for an example I realize that debugfs can exceed page
> > > size. Is it that hard to expose a sysfs file larger than page size?
> > 
> > No, there is a simple way to do it, but I'm not going to show you how as
> > it is NOT how to use sysfs at all :)
> >
> > Why are you wanting to dump this whole mess into one file
> 
> I wouldn't call a whitespace separated list of CPU feature flags a mess...

It's a mess in that it's more than one value and you want to overflow a
PAGE_SIZE sometime in the future with it :(

> > and then parse
> > it, it's no different from having 100+ different sysfs files and then
> > doing a readdir(3) on the thing, right?
> 
> If this is the way it "has to"/should/"is designed for" to export such
> (not that complex) data via sysfs...
> 
> I do not have such a strong opinion on the how, this is up to maintainers
> to discuss.
> 
> I hope it is agreed that this info is worth exporting via sysfs.

I don't think anyone is saying it is worth exporting this information
via sysfs at all here.

thanks,

greg k-h

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Wed, Dec 11, 2019 at 03:12:51PM +0100, Thomas Renninger wrote:
> On Wednesday, December 11, 2019 2:56:19 PM CET Greg KH wrote:
> > On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:
> > > If Greg (and others) are ok, I would add "page size exceeding" handling.
> > > Hm, quick searching for an example I realize that debugfs can exceed page
> > > size. Is it that hard to expose a sysfs file larger than page size?
> > 
> > No, there is a simple way to do it, but I'm not going to show you how as
> > it is NOT how to use sysfs at all :)
> >
> > Why are you wanting to dump this whole mess into one file
> 
> I wouldn't call a whitespace separated list of CPU feature flags a mess...

It's a mess in that it's more than one value and you want to overflow a
PAGE_SIZE sometime in the future with it :(

> > and then parse
> > it, it's no different from having 100+ different sysfs files and then
> > doing a readdir(3) on the thing, right?
> 
> If this is the way it "has to"/should/"is designed for" to export such
> (not that complex) data via sysfs...
> 
> I do not have such a strong opinion on the how, this is up to maintainers
> to discuss.
> 
> I hope it is agreed that this info is worth exporting via sysfs.

I don't think anyone is saying it is worth exporting this information
via sysfs at all here.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Renninger]

On Wednesday, December 11, 2019 3:26:47 PM CET Greg KH wrote:
> On Wed, Dec 11, 2019 at 03:12:51PM +0100, Thomas Renninger wrote:
> > On Wednesday, December 11, 2019 2:56:19 PM CET Greg KH wrote:
> > > On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:

...

> > I hope it is agreed that this info is worth exporting via sysfs.
> 
> I don't think anyone is saying it is worth exporting this information
> via sysfs at all here.

Ok. I go for cpuid userspace tool then.

I'd still say general files like:
cpu/info/{name,vendor}
make sense, so that if exported by an arch like in cpuinfo, it should show up 
in the same file.
Every cpu has a model name and a vendor and cpuid is x86 only.

If there should be need for /sys/devices/cpu/cpu0.. info/feature/name
whatever in the future..., let me know ;)

   Thomas

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Thomas Renninger]

On Wednesday, December 11, 2019 3:26:47 PM CET Greg KH wrote:
> On Wed, Dec 11, 2019 at 03:12:51PM +0100, Thomas Renninger wrote:
> > On Wednesday, December 11, 2019 2:56:19 PM CET Greg KH wrote:
> > > On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:

...

> > I hope it is agreed that this info is worth exporting via sysfs.
> 
> I don't think anyone is saying it is worth exporting this information
> via sysfs at all here.

Ok. I go for cpuid userspace tool then.

I'd still say general files like:
cpu/info/{name,vendor}
make sense, so that if exported by an arch like in cpuinfo, it should show up 
in the same file.
Every cpu has a model name and a vendor and cpuid is x86 only.

If there should be need for /sys/devices/cpu/cpu0.. info/feature/name
whatever in the future..., let me know ;)

   Thomas



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Wed, Dec 11, 2019 at 03:52:33PM +0100, Thomas Renninger wrote:
> On Wednesday, December 11, 2019 3:26:47 PM CET Greg KH wrote:
> > On Wed, Dec 11, 2019 at 03:12:51PM +0100, Thomas Renninger wrote:
> > > On Wednesday, December 11, 2019 2:56:19 PM CET Greg KH wrote:
> > > > On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:
> 
> ...
> 
> > > I hope it is agreed that this info is worth exporting via sysfs.
> > 
> > I don't think anyone is saying it is worth exporting this information
> > via sysfs at all here.
> 
> Ok. I go for cpuid userspace tool then.
> 
> I'd still say general files like:
> cpu/info/{name,vendor}
> make sense, so that if exported by an arch like in cpuinfo, it should show up 
> in the same file.
> Every cpu has a model name and a vendor and cpuid is x86 only.

I think you just saw the ARM developers arguing about model names, so I
don't think people will agree with that :)

goo dluck!

greg k-h

Re: [PATCH 2/3] x86 cpuinfo: implement sysfs nodes for x86

[Greg KH]

On Wed, Dec 11, 2019 at 03:52:33PM +0100, Thomas Renninger wrote:
> On Wednesday, December 11, 2019 3:26:47 PM CET Greg KH wrote:
> > On Wed, Dec 11, 2019 at 03:12:51PM +0100, Thomas Renninger wrote:
> > > On Wednesday, December 11, 2019 2:56:19 PM CET Greg KH wrote:
> > > > On Wed, Dec 11, 2019 at 11:42:35AM +0100, Thomas Renninger wrote:
> 
> ...
> 
> > > I hope it is agreed that this info is worth exporting via sysfs.
> > 
> > I don't think anyone is saying it is worth exporting this information
> > via sysfs at all here.
> 
> Ok. I go for cpuid userspace tool then.
> 
> I'd still say general files like:
> cpu/info/{name,vendor}
> make sense, so that if exported by an arch like in cpuinfo, it should show up 
> in the same file.
> Every cpu has a model name and a vendor and cpuid is x86 only.

I think you just saw the ARM developers arguing about model names, so I
don't think people will agree with that :)

goo dluck!

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel