3
0
forked from pool/util-linux

Accepting request 487529 from home:algraf:branches:Base:System

- Prefer sysfs exported SMBIOS3 tables in lscu (bsc#1033718)
  + arm64-lscpu-use-sysfs-for-table-access-if-available.patch

OBS-URL: https://build.opensuse.org/request/show/487529
OBS-URL: https://build.opensuse.org/package/show/Base:System/util-linux?expand=0&rev=340
This commit is contained in:
Stanislav Brabec 2017-04-12 13:18:50 +00:00 committed by Git OBS Bridge
parent db4edfc1a4
commit 48a100787f
3 changed files with 80 additions and 0 deletions

View File

@ -0,0 +1,71 @@
Return-Path: <ard.biesheuvel@linaro.org>
Delivered-To: agraf@imap.suse.de
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: util-linux-ng@vger.kernel.org
Cc: leif.lindholm@linaro.org,
agraf@suse.de,
kzak@redhat.com,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH] lspcu: use sysfs for table access if available
Date: Wed, 12 Apr 2017 10:11:29 +0100
Message-Id: <20170412091129.27283-1-ard.biesheuvel@linaro.org>
X-Mailer: git-send-email 2.9.3
On ARM systems, accessing SMBIOS tables via /dev/mem using read()
calls is not supported. The reason is that such tables are usually
located in EFI_RUNTIME_SERVICE_DATA memory, which is not covered
by the linear mapping on those systems, and so read() calls will
fail.
So instead, use the /sys/firmware/dmi/tables/DMI sysfs file, which
contains the entire structure table array, and will be available
on any recent Linux system, even on ones that only export the rev3
SMBIOS entry point, which is currently ignored by lscpu.
Note that the max 'num' value is inferred from the size. This is not
a limitation of the sysfs interface, but a limitation of the rev3
entry point, which no longer carries a number of array elements.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
sys-utils/lscpu-dmi.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/sys-utils/lscpu-dmi.c b/sys-utils/lscpu-dmi.c
index 0e497d10c..a8298ff74 100644
--- a/sys-utils/lscpu-dmi.c
+++ b/sys-utils/lscpu-dmi.c
@@ -192,6 +192,18 @@ static int hypervisor_decode_smbios(uint8_t *buf, const char *devmem)
devmem);
}
+static int hypervisor_decode_sysfw(void)
+{
+ static char const sys_fw_dmi_tables[] = "/sys/firmware/dmi/tables/DMI";
+ struct stat st;
+
+ if (stat(sys_fw_dmi_tables, &st))
+ return -1;
+
+ return hypervisor_from_dmi_table(0, st.st_size, st.st_size / 4,
+ sys_fw_dmi_tables);
+}
+
/*
* Probe for EFI interface
*/
@@ -242,6 +254,10 @@ int read_hypervisor_dmi(void)
|| '\0' != 0)
return rc;
+ rc = hypervisor_decode_sysfw();
+ if (rc >= 0)
+ return rc;
+
/* First try EFI (ia64, Intel-based Mac) */
switch (address_from_efi(&fp)) {
case EFI_NOT_FOUND:
--
2.11.0

View File

@ -1,3 +1,9 @@
-------------------------------------------------------------------
Wed Apr 12 09:19:21 UTC 2017 - agraf@suse.com
- Prefer sysfs exported SMBIOS3 tables in lscu (bsc#1033718)
+ arm64-lscpu-use-sysfs-for-table-access-if-available.patch
-------------------------------------------------------------------
Thu Apr 6 17:35:34 CEST 2017 - sbrabec@suse.com

View File

@ -157,6 +157,8 @@ Source51: blkid.conf
Patch0: make-sure-sbin-resp-usr-sbin-are-in-PATH.diff
# PATCH-FEATURE-SLE util-linux-losetup-Add-support-for-setting-logical-blocksize.patch bsc931634 FATE319010 hare@suse.de -- Add support for setting logical blocksizes.
Patch1: util-linux-losetup-Add-support-for-setting-logical-blocksize.patch
# PATCH-BUG-FIX arm64-lscpu-use-sysfs-for-table-access-if-available.patch bsc#1033718 agraf@suse.de -- Use SMBIOS3 tables when available in lscpu
Patch2: arm64-lscpu-use-sysfs-for-table-access-if-available.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-build
#
%if %build_util_linux
@ -411,6 +413,7 @@ library.
# logical block size support in loop does not exist in Tumbleweed and upstream kernel yet
%patch1 -p1
%endif
%patch2 -p1
#
# setctsid
cp -p %{S:22} %{S:23} .