handle Linux systems without /dev/mem

PATCH In review Al Stone 2 participants 10 messages Jun 4, 2015 – Jun 16, 2015 ACPI component architecture (acpica)

Share & tools

Al Stone

author

2015-06-04 00:43 UTC #0 lore raw

PATCH 1/1 handle Linux systems without /dev/mem

On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.

The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.

This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.

Signed-off-by Al Stone <ahs3(a)redhat.com>

Signature · 8 lines

ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

generate/unix/acpidump/Makefile +7 -0

diff -Naur acpica-unix2-20150515/generate/unix/acpidump/Makefile acpica-unix2-20150515.devmem/generate/unix/acpidump/Makefile
@@ -67,10 +67,17 @@
 OBJECTS += \
 	$(OBJDIR)/osbsdtbl.o
 else
+
+ifeq ($(NO_DEV_MEM), true)
+OBJECTS += \
+	$(OBJDIR)/oslinuxtbl_nodevmem.o
+else
 OBJECTS += \
 	$(OBJDIR)/oslinuxtbl.o
 endif
 
+endif
+
 #
 # Flags specific to acpidump
 #

generate/unix/Makefile.config +7 -0

diff -Naur acpica-unix2-20150515/generate/unix/Makefile.config acpica-unix2-20150515.devmem/generate/unix/Makefile.config
@@ -49,6 +49,7 @@
 LINKPROG =   $(CC) $(OBJECTS) -o $(PROG) $(LDFLAGS) $(OPT_LDFLAGS)
 PREFIX ?=    /usr
 INSTALLDIR = $(PREFIX)/bin
+UNAME_M := $(shell uname -m)
 UNAME_S := $(shell uname -s)
 
 #

@@ -70,6 +71,12 @@
 HOST =       _NetBSD
 endif
 
+ifeq ($(UNAME_S), Linux)
+ifeq ($(UNAME_M), aarch64)
+NO_DEV_MEM ?= true
+endif
+endif
+
 ifeq ($(HOST), _APPLE)
 INSTALL  =   cp
 INSTALLFLAGS ?= -f

source/os_specific/service_layers/oslinuxtbl_nodevmem.c +734 -0

734 lines not on this page · raw message

Zheng

2015-06-09 06:16 UTC #1 lore raw

Hi,

The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.

We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77

Thanks and best regards
-Lv

Quoted 29 lines

From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Al Stone

author

2015-06-12 22:00 UTC #2 lore raw

Quoted 8 lines · Lv

Hi,
The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.

Quoted 7 lines

We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77
Thanks and best regards
-Lv

The problem I have with this fix for the issue is that this command:

	# acpidump -n APIC

will work on x86 but fail on arm64. Getting the -c option to work properly is a good thing, and should be done regardless. But, this means we have to use "acpidump -c -n APIC" on systems without /dev/mem. For my part:

(a) these are not really customized tables, but the standard ACPI tables used to boot the system, so using -c is a little confusing, and

(b) we now have to use different commands on different architectures to get the same result.

My preference would be that the same command has the same behavior everywhere, which is why I patched it the way I did.

This happens to be very useful on arm64 where /dev/mem is not reliable, but it could also be usable on any system that does not want to expose /dev/mem for some reason. I think the advantage of the patch sent is that the user command stays the same no matter what the situation.

Quoted 29 lines

Quoted 29 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Signature · 8 lines

ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Zheng

2015-06-15 00:39 UTC #3 lore raw

Hi,

Quoted 28 lines

From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Saturday, June 13, 2015 6:00 AM
Quoted 8 lines · Lv
Hi,
The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.
Quoted 7 lines
We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77
Thanks and best regards
-Lv
The problem I have with this fix for the issue is that this command:
	# acpidump -n APIC
will work on x86 but fail on arm64. Getting the -c option to work properly is a good thing, and should be done regardless. But, this means we have to use "acpidump -c -n APIC" on systems without /dev/mem. For my part:

Quoted 8 lines

(a) these are not really customized tables, but the standard ACPI tables used to boot the system, so using -c is a little confusing, and
(b) we now have to use different commands on different architectures to get the same result.
My preference would be that the same command has the same behavior everywhere, which is why I patched it the way I did.

This is not our preference, though...
I've been in the trouble of being easily confused by the bug reporters.
And I cannot distinguish if the table has been customized or root cause the bugs if the reporter did what I asked for but hid what he silently did. If we cannot distinguish the BIOS provided tables and the user customized tables from users' output, we'll likely lose the capability of taking evidence...

Quoted 5 lines

This happens to be very useful on arm64 where /dev/mem is not reliable, but it could also be usable on any system that does not want to expose /dev/mem for some reason. I think the advantage of the patch sent is that the user command stays the same no matter what the situation.

My suggestion would be to support this via kernel.
Let the kernel exposes 2 kind of tables (customized or not customized) into the /sys/firmware/acpi/tables. Which can meet both of the requirements.

Thanks and best regards
-Lv

Quoted 41 lines

Quoted 21 lines
Quoted 21 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
Quoted 9 lines
Quoted 9 lines
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Al Stone

author

2015-06-15 21:36 UTC #4 lore raw

Quoted 36 lines · Lv

Hi,
Quoted 34 lines
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Saturday, June 13, 2015 6:00 AM
Quoted 8 lines · Lv
Hi,
The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.
Quoted 7 lines
We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77
Thanks and best regards
-Lv
The problem I have with this fix for the issue is that this command:
	# acpidump -n APIC
will work on x86 but fail on arm64. Getting the -c option to work properly is a good thing, and should be done regardless. But, this means we have to use "acpidump -c -n APIC" on systems without /dev/mem. For my part:
(a) these are not really customized tables, but the standard ACPI tables used to boot the system, so using -c is a little confusing, and
(b) we now have to use different commands on different architectures to get the same result.

Quoted 7 lines

Quoted 2 lines
My preference would be that the same command has the same behavior everywhere, which is why I patched it the way I did.
This is not our preference, though...
I've been in the trouble of being easily confused by the bug reporters.
And I cannot distinguish if the table has been customized or root cause the bugs if the reporter did what I asked for but hid what he silently did. If we cannot distinguish the BIOS provided tables and the user customized tables from users' output, we'll likely lose the capability of taking evidence...

Understood; I was in technical support roles for many years.

Perhaps I am misunderstanding this use of the word "customized." On ARM, the only way I can be sure to get the tables supplied by UEFI is to use the UEFI shell and dump them. Once the OS has booted, the tables in /sys/firmware/acpi are what the system is currently using, and those are the ones I'm interested in using for debugging when something breaks. So, unless I have replaced the DSDT in the initrd, or added SSDTs, /sys/firmware/acpi will be exactly the same as what UEFI provided. Even then, those are the tables I want to see if there is a problem since those are the ones being used. Is that what "customized" means, in this case: the actual run-time tables and not the tables provided by UEFI?

Quoted 8 lines

Quoted 4 lines
This happens to be very useful on arm64 where /dev/mem is not reliable, but it could also be usable on any system that does not want to expose /dev/mem for some reason. I think the advantage of the patch sent is that the user command stays the same no matter what the situation.
My suggestion would be to support this via kernel.
Let the kernel exposes 2 kind of tables (customized or not customized) into the /sys/firmware/acpi/tables. Which can meet both of the requirements.

Okay, this sort of answers my questions. "Customized" is not the word I would have chosen for this -- I think I would have made it /sys/firmware/acpi/tables/current (i.e., "customized") and /sys/firmware/acpi/tables/boot (i.e.,
not "customized"). When I was thinking of tables as being customized, I was thinking of new versions of all kinds of tables, not just the DSDT and SSDTs. On ARM, going in and out of ACPI mode is just not allowed so there's really no opportunity to customize the tables much, other than adding SSDTs.

Creating new sysfs entries in a kernel driver would be simple enough to do; the issue would be getting it accepted. On x86, there's no guarantee that the BIOS tables and run-time tables are the same, so customized and not customized may be very different, and these kernel changes would make sense. On ARMv8, the boot and run-time tables will be essentially identical most of the time so it's not clear there's a lot of value in adding more stuff to sysfs. If I create this kernel code, though, it seems to me it would make sense to change acpidump so it does not use /dev/mem for any architecture, but always uses sysfs on all architectures -- do you agree?

I'll take a look at doing this on the kernel side...

Quoted 44 lines

Thanks and best regards
-Lv
Quoted 41 lines
Quoted 21 lines
Quoted 21 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
Quoted 9 lines
Quoted 9 lines
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Signature · 8 lines

ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Zheng

2015-06-16 00:41 UTC #5 lore raw

Hi,

Quoted 52 lines

From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Tuesday, June 16, 2015 5:37 AM
Quoted 36 lines · Lv
Hi,
Quoted 34 lines
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Saturday, June 13, 2015 6:00 AM
Quoted 8 lines · Lv
Hi,
The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.
Quoted 7 lines
We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77
Thanks and best regards
-Lv
The problem I have with this fix for the issue is that this command:
	# acpidump -n APIC
will work on x86 but fail on arm64. Getting the -c option to work properly is a good thing, and should be done regardless. But, this means we have to use "acpidump -c -n APIC" on systems without /dev/mem. For my part:
(a) these are not really customized tables, but the standard ACPI tables used to boot the system, so using -c is a little confusing, and
(b) we now have to use different commands on different architectures to get the same result.
Quoted 6 lines
Quoted 2 lines
My preference would be that the same command has the same behavior everywhere, which is why I patched it the way I did.
This is not our preference, though...
I've been in the trouble of being easily confused by the bug reporters.
And I cannot distinguish if the table has been customized or root cause the bugs if the reporter did what I asked for but hid what he
silently did.
Quoted 1 line
If we cannot distinguish the BIOS provided tables and the user customized tables from users' output, we'll likely lose the capability of
taking evidence...
Understood; I was in technical support roles for many years.

Quoted 10 lines

Perhaps I am misunderstanding this use of the word "customized." On ARM, the only way I can be sure to get the tables supplied by UEFI is to use the UEFI shell and dump them. Once the OS has booted, the tables in /sys/firmware/acpi are what the system is currently using, and those are the ones I'm interested in using for debugging when something breaks. So, unless I have replaced the DSDT in the initrd, or added SSDTs, /sys/firmware/acpi will be exactly the same as what UEFI provided. Even then, those are the tables I want to see if there is a problem since those are the ones being used. Is that what "customized" means, in this case: the actual run-time tables and not the tables provided by UEFI?

Yes, so the "customized" tables should be dumped by default as you've suggested.

Quoted 19 lines

Quoted 9 lines
Quoted 5 lines
This happens to be very useful on arm64 where /dev/mem is not reliable, but it could also be usable on any system that does not want to expose /dev/mem for some reason. I think the advantage of the patch sent is that the user command stays the same no matter what the situation.
My suggestion would be to support this via kernel.
Let the kernel exposes 2 kind of tables (customized or not customized) into the /sys/firmware/acpi/tables. Which can meet both of the requirements.
Okay, this sort of answers my questions. "Customized" is not the word I would have chosen for this -- I think I would have made it /sys/firmware/acpi/tables/current (i.e., "customized") and /sys/firmware/acpi/tables/boot (i.e.,
not "customized"). When I was thinking of tables as being customized, I was thinking of new versions of all kinds of tables, not just the DSDT and SSDTs. On ARM, going in and out of ACPI mode is just not allowed so there's really no opportunity to customize the tables much, other than adding SSDTs.

Quoted 9 lines

Creating new sysfs entries in a kernel driver would be simple enough to do; the issue would be getting it accepted. On x86, there's no guarantee that the BIOS tables and run-time tables are the same, so customized and not customized may be very different, and these kernel changes would make sense. On ARMv8, the boot and run-time tables will be essentially identical most of the time so it's not clear there's a lot of value in adding more stuff to sysfs. If I create this kernel code, though, it seems to me it would make sense to change acpidump so it does not use /dev/mem for any architecture, but always uses sysfs on all architectures -- do you agree?

IMO, we could do this better.
Users won't want to see the original BIOS tables.
So the BIOS tables needn't appear in the userspace unless required, thus we could export them via debugfs.

Or even better:
We could provide some ioctl or sysctl from kernel to allow acpidump to obtain what it want, for example:
1. Find RSDP
2. Validate and dump a table from any address (we need to support Load/LoadTable opcodes)

Quoted 2 lines

I'll take a look at doing this on the kernel side...

Thanks.

Best regards
-Lv

Quoted 56 lines

Quoted 45 lines
Thanks and best regards
-Lv
Quoted 41 lines
Quoted 21 lines
Quoted 21 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
Quoted 9 lines
Quoted 9 lines
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Zheng

2015-06-15 00:48 UTC #6 lore raw

In reply to Al Stone

Hi,

Quoted 52 lines

From: Zheng, Lv
Sent: Monday, June 15, 2015 8:40 AM
To: 'Al Stone'; devel(a)acpica.org
Subject: RE: [Devel] [PATCH] handle Linux systems without /dev/mem
Hi,
Quoted 28 lines
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Saturday, June 13, 2015 6:00 AM
Quoted 8 lines · Lv
Hi,
The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.
Quoted 7 lines
We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77
Thanks and best regards
-Lv
The problem I have with this fix for the issue is that this command:
	# acpidump -n APIC
will work on x86 but fail on arm64. Getting the -c option to work properly is a good thing, and should be done regardless. But, this means we have to use "acpidump -c -n APIC" on systems without /dev/mem. For my part:
Quoted 8 lines
(a) these are not really customized tables, but the standard ACPI tables used to boot the system, so using -c is a little confusing, and
(b) we now have to use different commands on different architectures to get the same result.
My preference would be that the same command has the same behavior everywhere, which is why I patched it the way I did.
This is not our preference, though...
I've been in the trouble of being easily confused by the bug reporters.
And I cannot distinguish if the table has been customized or root cause the bugs if the reporter did what I asked for but hid what he silently did.
If we cannot distinguish the BIOS provided tables and the user customized tables from users' output, we'll likely lose the capability of taking evidence...
Quoted 1 line

Quoted 8 lines

Quoted 4 lines
This happens to be very useful on arm64 where /dev/mem is not reliable, but it could also be usable on any system that does not want to expose /dev/mem for some reason. I think the advantage of the patch sent is that the user command stays the same no matter what the situation.
My suggestion would be to support this via kernel.
Let the kernel exposes 2 kind of tables (customized or not customized) into the /sys/firmware/acpi/tables. Which can meet both of the requirements.

Or we currently can make the "-c" mode the default behavior and add a new option for dumping the BIOS tables.

Thanks and best regards
-Lv

Quoted 45 lines

Thanks and best regards
-Lv
Quoted 41 lines
Quoted 21 lines
Quoted 21 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
Quoted 9 lines
Quoted 9 lines
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Zheng

2015-06-15 01:13 UTC #7 lore raw

Hi,

Quoted 60 lines

From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Zheng, Lv
Sent: Monday, June 15, 2015 8:49 AM
Hi,
Quoted 55 lines
From: Zheng, Lv
Sent: Monday, June 15, 2015 8:40 AM
Hi,
Quoted 28 lines
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Saturday, June 13, 2015 6:00 AM
Quoted 8 lines · Lv
Hi,
The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.
Quoted 7 lines
We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77
Thanks and best regards
-Lv
The problem I have with this fix for the issue is that this command:
	# acpidump -n APIC
will work on x86 but fail on arm64. Getting the -c option to work properly is a good thing, and should be done regardless. But, this means we have to use "acpidump -c -n APIC" on systems without /dev/mem. For my part:
Quoted 8 lines
(a) these are not really customized tables, but the standard ACPI tables used to boot the system, so using -c is a little confusing, and
(b) we now have to use different commands on different architectures to get the same result.
My preference would be that the same command has the same behavior everywhere, which is why I patched it the way I did.
This is not our preference, though...
I've been in the trouble of being easily confused by the bug reporters.
And I cannot distinguish if the table has been customized or root cause the bugs if the reporter did what I asked for but hid what he silently did.
If we cannot distinguish the BIOS provided tables and the user customized tables from users' output, we'll likely lose the capability of taking evidence...
Quoted 5 lines
This happens to be very useful on arm64 where /dev/mem is not reliable, but it could also be usable on any system that does not want to expose /dev/mem for some reason. I think the advantage of the patch sent is that the user command stays the same no matter what the situation.

Quoted 5 lines

Quoted 3 lines
My suggestion would be to support this via kernel.
Let the kernel exposes 2 kind of tables (customized or not customized) into the /sys/firmware/acpi/tables. Which can meet both of the requirements.
Or we currently can make the "-c" mode the default behavior and add a new option for dumping the BIOS tables.

And you can check if this commit is acceptable:
https://github.com/acpica/acpica/pull/80

Thanks and best regards
-Lv

Quoted 54 lines

Thanks and best regards
-Lv
Quoted 45 lines
Thanks and best regards
-Lv
Quoted 41 lines
Quoted 21 lines
Quoted 21 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
Quoted 9 lines
Quoted 9 lines
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
_______________________________________________
Devel mailing list
Devel(a)acpica.org
https://lists.acpica.org/mailman/listinfo/devel

Al Stone

author

2015-06-15 21:42 UTC #8 lore raw

Quoted 62 lines · Lv

Hi,
Quoted 60 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Zheng, Lv
Sent: Monday, June 15, 2015 8:49 AM
Hi,
Quoted 55 lines
From: Zheng, Lv
Sent: Monday, June 15, 2015 8:40 AM
Hi,
Quoted 28 lines
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Saturday, June 13, 2015 6:00 AM
Quoted 8 lines · Lv
Hi,
The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.
Quoted 7 lines
We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77
Thanks and best regards
-Lv
The problem I have with this fix for the issue is that this command:
	# acpidump -n APIC
will work on x86 but fail on arm64. Getting the -c option to work properly is a good thing, and should be done regardless. But, this means we have to use "acpidump -c -n APIC" on systems without /dev/mem. For my part:
Quoted 8 lines
(a) these are not really customized tables, but the standard ACPI tables used to boot the system, so using -c is a little confusing, and
(b) we now have to use different commands on different architectures to get the same result.
My preference would be that the same command has the same behavior everywhere, which is why I patched it the way I did.
This is not our preference, though...
I've been in the trouble of being easily confused by the bug reporters.
And I cannot distinguish if the table has been customized or root cause the bugs if the reporter did what I asked for but hid what he silently did.
If we cannot distinguish the BIOS provided tables and the user customized tables from users' output, we'll likely lose the capability of taking evidence...
Quoted 5 lines
This happens to be very useful on arm64 where /dev/mem is not reliable, but it could also be usable on any system that does not want to expose /dev/mem for some reason. I think the advantage of the patch sent is that the user command stays the same no matter what the situation.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
My suggestion would be to support this via kernel.
Let the kernel exposes 2 kind of tables (customized or not customized) into the /sys/firmware/acpi/tables. Which can meet both of the requirements.
Or we currently can make the "-c" mode the default behavior and add a new option for dumping the BIOS tables.
And you can check if this commit is acceptable:
https://github.com/acpica/acpica/pull/80

Hrm. I guess if we have to have the -c option, I would prefer the first patch where we just get rid of the dependence on /dev/mem. I think it is easier to explain that -c must always be used rather than trying to explain how to use the -c on/off options.

I think the path I would like to see long term is to split up /sys as you suggested so that there is a run-time version of the ACPI tables, and a copy of the tables from UEFI. That way, no one has to rely on /dev/mem at all, and acpidump can go back to parameters operating exactly the same way on all possible platforms.

Quoted 57 lines

Thanks and best regards
-Lv
Quoted 54 lines
Thanks and best regards
-Lv
Quoted 45 lines
Thanks and best regards
-Lv
Quoted 41 lines
Quoted 21 lines
Quoted 21 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
Quoted 9 lines
Quoted 9 lines
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
_______________________________________________
Devel mailing list
Devel(a)acpica.org
https://lists.acpica.org/mailman/listinfo/devel

Signature · 8 lines

ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Zheng

2015-06-16 00:33 UTC #9 lore raw

Hi,

Quoted 74 lines

From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Tuesday, June 16, 2015 5:42 AM
Quoted 52 lines · Lv
Hi,
Quoted 50 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Zheng, Lv
Sent: Monday, June 15, 2015 8:49 AM
Hi,
Quoted 45 lines
From: Zheng, Lv
Sent: Monday, June 15, 2015 8:40 AM
Hi,
Quoted 28 lines
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Saturday, June 13, 2015 6:00 AM
Quoted 8 lines · Lv
Hi,
The patch is wrong.
If we want to dump tables without accessing /dev/mem, we have acpidump -c. The only problem here is:
There is a bug that even with -c specified, acpidump cannot work without accessing /dev/mem. So we shouldn't introduce a new portable acpidump OSL but should fix the very problem.
Quoted 7 lines
We've noticed the similar issue in handling this kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=87971
The fix for this issue can be found here:
https://github.com/acpica/acpica/pull/77
Thanks and best regards
-Lv
The problem I have with this fix for the issue is that this command:
	# acpidump -n APIC
will work on x86 but fail on arm64. Getting the -c option to work properly is a good thing, and should be done regardless. But, this means we have to use "acpidump -c -n APIC" on systems without /dev/mem. For my part:
Quoted 8 lines
(a) these are not really customized tables, but the standard ACPI tables used to boot the system, so using -c is a little confusing, and
(b) we now have to use different commands on different architectures to get the same result.
My preference would be that the same command has the same behavior everywhere, which is why I patched it the way I did.
This is not our preference, though...
I've been in the trouble of being easily confused by the bug reporters.
And I cannot distinguish if the table has been customized or root cause the bugs if the reporter did what I asked for but hid what
he
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
silently did.
If we cannot distinguish the BIOS provided tables and the user customized tables from users' output, we'll likely lose the capability
of
Quoted 14 lines
Quoted 13 lines
Quoted 11 lines
taking evidence...
Quoted 5 lines
This happens to be very useful on arm64 where /dev/mem is not reliable, but it could also be usable on any system that does not want to expose /dev/mem for some reason. I think the advantage of the patch sent is that the user command stays the same no matter what the situation.
My suggestion would be to support this via kernel.
Let the kernel exposes 2 kind of tables (customized or not customized) into the /sys/firmware/acpi/tables. Which can meet both of the requirements.
Or we currently can make the "-c" mode the default behavior and add a new option for dumping the BIOS tables.

Quoted 7 lines

Quoted 2 lines
And you can check if this commit is acceptable:
https://github.com/acpica/acpica/pull/80
Hrm. I guess if we have to have the -c option, I would prefer the first patch where we just get rid of the dependence on /dev/mem. I think it is easier to explain that -c must always be used rather than trying to explain how to use the -c on/off options.

We can switch this option back when the support is ready.

Quoted 6 lines

I think the path I would like to see long term is to split up /sys as you suggested so that there is a run-time version of the ACPI tables, and a copy of the tables from UEFI. That way, no one has to rely on /dev/mem at all, and acpidump can go back to parameters operating exactly the same way on all possible platforms.

Removing the dependency of /dev/mem and exporting BIOS table via /sys or even better - making all acpidump functionalities a part of the kernel. I think we need to add one more pointer in acpi_table_desc first.

Thanks and best regards
-Lv

Quoted 69 lines

Quoted 58 lines
Thanks and best regards
-Lv
Quoted 54 lines
Thanks and best regards
-Lv
Quoted 45 lines
Thanks and best regards
-Lv
Quoted 41 lines
Quoted 21 lines
Quoted 21 lines
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Thursday, June 04, 2015 8:43 AM
On arm64 systems in particular, the use of /dev/mem is not recommended. The contents may or may not be valid depending on the memory map being used, since they are not standardized.
The attached patch will cause arm64 (aka ARMv8 or AArch64) Linux systems to use a new file called source/os_specific/service_layers/oslinuxtbl_nodevmem.c (a subset of the oslinuxtbl.c code) that allows acpidump to read all ACPI tables from /sys/firmware/acpi instead of from /dev/mem. This will help ensure that the tables retrieved are the ones actually being used and that their content is correct.
This patch applies on top of the 20150515 version, and I have included it in the 20150515-2 versions of the Fedora and Debian packages. I've tried the resulting acpidump on x86, x86_64 and arm64 systems and it seems to work well.
Signed-off-by Al Stone <ahs3(a)redhat.com>
Quoted 9 lines
Quoted 9 lines
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
_______________________________________________
Devel mailing list
Devel(a)acpica.org
https://lists.acpica.org/mailman/listinfo/devel
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------