[PATCH v2 0/5] beautify EFI memmap logs

[PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

changes in v2:
- explain with examples how the log's appearance changes, in patches 3-5
  [Ingo]

v1 blurb:

> It's a pain to analyze EFI memmap logs while debugging, especially to
> verify the memory types (an enum) and the memory attributes (a
> bitmap). This series renders those columns human-readable, and unifies
> their formatting between x86, ia64 and arm64.

Thanks
Laszlo

Laszlo Ersek (5):
  efi: add macro for EFI_MEMORY_UCE memory attribute
  efi: introduce efi_md_typeattr_format()
  x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
  ia64: efi: format EFI memory type & attrs with
    efi_md_typeattr_format()
  arm64: efi: format EFI memory type & attrs with
    efi_md_typeattr_format()

 include/linux/efi.h         |  8 +++++++
 arch/arm64/kernel/efi.c     | 26 +++++----------------
 arch/ia64/kernel/efi.c      |  6 +++--
 arch/x86/platform/efi/efi.c |  7 ++++--
 drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 80 insertions(+), 24 deletions(-)

-- 
1.8.3.1

[PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

changes in v2:
- explain with examples how the log's appearance changes, in patches 3-5
  [Ingo]

v1 blurb:

> It's a pain to analyze EFI memmap logs while debugging, especially to
> verify the memory types (an enum) and the memory attributes (a
> bitmap). This series renders those columns human-readable, and unifies
> their formatting between x86, ia64 and arm64.

Thanks
Laszlo

Laszlo Ersek (5):
  efi: add macro for EFI_MEMORY_UCE memory attribute
  efi: introduce efi_md_typeattr_format()
  x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
  ia64: efi: format EFI memory type & attrs with
    efi_md_typeattr_format()
  arm64: efi: format EFI memory type & attrs with
    efi_md_typeattr_format()

 include/linux/efi.h         |  8 +++++++
 arch/arm64/kernel/efi.c     | 26 +++++----------------
 arch/ia64/kernel/efi.c      |  6 +++--
 arch/x86/platform/efi/efi.c |  7 ++++--
 drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 80 insertions(+), 24 deletions(-)

-- 
1.8.3.1

[PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

changes in v2:
- explain with examples how the log's appearance changes, in patches 3-5
  [Ingo]

v1 blurb:

> It's a pain to analyze EFI memmap logs while debugging, especially to
> verify the memory types (an enum) and the memory attributes (a
> bitmap). This series renders those columns human-readable, and unifies
> their formatting between x86, ia64 and arm64.

Thanks
Laszlo

Laszlo Ersek (5):
  efi: add macro for EFI_MEMORY_UCE memory attribute
  efi: introduce efi_md_typeattr_format()
  x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
  ia64: efi: format EFI memory type & attrs with
    efi_md_typeattr_format()
  arm64: efi: format EFI memory type & attrs with
    efi_md_typeattr_format()

 include/linux/efi.h         |  8 +++++++
 arch/arm64/kernel/efi.c     | 26 +++++----------------
 arch/ia64/kernel/efi.c      |  6 +++--
 arch/x86/platform/efi/efi.c |  7 ++++--
 drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 80 insertions(+), 24 deletions(-)

-- 
1.8.3.1

[PATCH v2 1/5] efi: add macro for EFI_MEMORY_UCE memory attribute

[Laszlo Ersek]

Add the following macro from the UEFI spec, for completeness:

  EFI_MEMORY_UCE  Memory cacheability attribute: The memory region
                  supports being configured as not cacheable, exported,
                  and supports the "fetch and add" semaphore mechanism.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 include/linux/efi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index 45cb4ff..b4b1d8d 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -92,6 +92,7 @@ typedef	struct {
 #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
 #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
 #define EFI_MEMORY_WB		((u64)0x0000000000000008ULL)	/* write-back */
+#define EFI_MEMORY_UCE		((u64)0x0000000000000010ULL)	/* uncached, exported */
 #define EFI_MEMORY_WP		((u64)0x0000000000001000ULL)	/* write-protect */
 #define EFI_MEMORY_RP		((u64)0x0000000000002000ULL)	/* read-protect */
 #define EFI_MEMORY_XP		((u64)0x0000000000004000ULL)	/* execute-protect */
-- 
1.8.3.1

[PATCH v2 1/5] efi: add macro for EFI_MEMORY_UCE memory attribute

[Laszlo Ersek]

Add the following macro from the UEFI spec, for completeness:

  EFI_MEMORY_UCE  Memory cacheability attribute: The memory region
                  supports being configured as not cacheable, exported,
                  and supports the "fetch and add" semaphore mechanism.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 include/linux/efi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index 45cb4ff..b4b1d8d 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -92,6 +92,7 @@ typedef	struct {
 #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
 #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
 #define EFI_MEMORY_WB		((u64)0x0000000000000008ULL)	/* write-back */
+#define EFI_MEMORY_UCE		((u64)0x0000000000000010ULL)	/* uncached, exported */
 #define EFI_MEMORY_WP		((u64)0x0000000000001000ULL)	/* write-protect */
 #define EFI_MEMORY_RP		((u64)0x0000000000002000ULL)	/* read-protect */
 #define EFI_MEMORY_XP		((u64)0x0000000000004000ULL)	/* execute-protect */
-- 
1.8.3.1

[PATCH v2 1/5] efi: add macro for EFI_MEMORY_UCE memory attribute

[Laszlo Ersek]

Add the following macro from the UEFI spec, for completeness:

  EFI_MEMORY_UCE  Memory cacheability attribute: The memory region
                  supports being configured as not cacheable, exported,
                  and supports the "fetch and add" semaphore mechanism.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 include/linux/efi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index 45cb4ff..b4b1d8d 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -92,6 +92,7 @@ typedef	struct {
 #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
 #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
 #define EFI_MEMORY_WB		((u64)0x0000000000000008ULL)	/* write-back */
+#define EFI_MEMORY_UCE		((u64)0x0000000000000010ULL)	/* uncached, exported */
 #define EFI_MEMORY_WP		((u64)0x0000000000001000ULL)	/* write-protect */
 #define EFI_MEMORY_RP		((u64)0x0000000000002000ULL)	/* read-protect */
 #define EFI_MEMORY_XP		((u64)0x0000000000004000ULL)	/* execute-protect */
-- 
1.8.3.1

[PATCH v2 2/5] efi: introduce efi_md_typeattr_format()

[Laszlo Ersek]

At the moment, there are three architectures debug-printing the EFI memory
map at initialization: x86, ia64, and arm64. They all use different format
strings, plus the EFI memory type and the EFI memory attributes are
similarly hard to decode for a human reader.

Introduce a helper __init function that formats the memory type and the
memory attributes in a unified way, to a user-provided character buffer.

The array "memory_type_name" is copied from the arm64 code, temporarily
duplicating it. The (otherwise optional) braces around each string literal
in the initializer list are dropped in order to match the kernel coding
style more closely. The element size is tightened from 32 to 20 bytes
(maximum actual string length + 1) so that we can derive the field width
from the element size.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 include/linux/efi.h        |  7 ++++++
 drivers/firmware/efi/efi.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index b4b1d8d..d04d618 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -887,6 +887,13 @@ extern bool efi_poweroff_required(void);
 	     (md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \
 	     (md) = (void *)(md) + (m)->desc_size)
 
+/*
+ * Format an EFI memory descriptor's type and attributes to a user-provided
+ * character buffer, as per snprintf(), and return the buffer.
+ */
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+				     const efi_memory_desc_t *md);
+
 /**
  * efi_range_is_wc - check the WC bit on an address range
  * @start: starting kvirt address
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 64ecbb5..43d9d25 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -423,3 +423,60 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose)
 	return ret;
 }
 #endif /* CONFIG_EFI_PARAMS_FROM_FDT */
+
+static __initdata char memory_type_name[][20] = {
+	"Reserved",
+	"Loader Code",
+	"Loader Data",
+	"Boot Code",
+	"Boot Data",
+	"Runtime Code",
+	"Runtime Data",
+	"Conventional Memory",
+	"Unusable Memory",
+	"ACPI Reclaim Memory",
+	"ACPI Memory NVS",
+	"Memory Mapped I/O",
+	"MMIO Port Space",
+	"PAL Code"
+};
+
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+				     const efi_memory_desc_t *md)
+{
+	char *pos;
+	int type_len;
+	register u64 attr;
+
+	pos = buf;
+	if (md->type >= ARRAY_SIZE(memory_type_name))
+		type_len = snprintf(pos, size, "[type=%u", md->type);
+	else
+		type_len = snprintf(pos, size, "[%-*s",
+				    (int)(sizeof(memory_type_name[0]) - 1),
+				    memory_type_name[md->type]);
+	if (type_len >= size)
+		return buf;
+
+	pos += type_len;
+	size -= type_len;
+
+	attr = md->attribute;
+	if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
+		     EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_WP |
+		     EFI_MEMORY_RP | EFI_MEMORY_XP | EFI_MEMORY_RUNTIME))
+		snprintf(pos, size, "|attr=0x%016llx]",
+			 (unsigned long long)attr);
+	else
+		snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
+			 attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
+			 attr & EFI_MEMORY_XP      ? "XP"  : "",
+			 attr & EFI_MEMORY_RP      ? "RP"  : "",
+			 attr & EFI_MEMORY_WP      ? "WP"  : "",
+			 attr & EFI_MEMORY_UCE     ? "UCE" : "",
+			 attr & EFI_MEMORY_WB      ? "WB"  : "",
+			 attr & EFI_MEMORY_WT      ? "WT"  : "",
+			 attr & EFI_MEMORY_WC      ? "WC"  : "",
+			 attr & EFI_MEMORY_UC      ? "UC"  : "");
+	return buf;
+}
-- 
1.8.3.1

[PATCH v2 2/5] efi: introduce efi_md_typeattr_format()

[Laszlo Ersek]

At the moment, there are three architectures debug-printing the EFI memory
map at initialization: x86, ia64, and arm64. They all use different format
strings, plus the EFI memory type and the EFI memory attributes are
similarly hard to decode for a human reader.

Introduce a helper __init function that formats the memory type and the
memory attributes in a unified way, to a user-provided character buffer.

The array "memory_type_name" is copied from the arm64 code, temporarily
duplicating it. The (otherwise optional) braces around each string literal
in the initializer list are dropped in order to match the kernel coding
style more closely. The element size is tightened from 32 to 20 bytes
(maximum actual string length + 1) so that we can derive the field width
from the element size.

Signed-off-by: Laszlo Ersek <lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 include/linux/efi.h        |  7 ++++++
 drivers/firmware/efi/efi.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index b4b1d8d..d04d618 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -887,6 +887,13 @@ extern bool efi_poweroff_required(void);
 	     (md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \
 	     (md) = (void *)(md) + (m)->desc_size)
 
+/*
+ * Format an EFI memory descriptor's type and attributes to a user-provided
+ * character buffer, as per snprintf(), and return the buffer.
+ */
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+				     const efi_memory_desc_t *md);
+
 /**
  * efi_range_is_wc - check the WC bit on an address range
  * @start: starting kvirt address
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 64ecbb5..43d9d25 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -423,3 +423,60 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose)
 	return ret;
 }
 #endif /* CONFIG_EFI_PARAMS_FROM_FDT */
+
+static __initdata char memory_type_name[][20] = {
+	"Reserved",
+	"Loader Code",
+	"Loader Data",
+	"Boot Code",
+	"Boot Data",
+	"Runtime Code",
+	"Runtime Data",
+	"Conventional Memory",
+	"Unusable Memory",
+	"ACPI Reclaim Memory",
+	"ACPI Memory NVS",
+	"Memory Mapped I/O",
+	"MMIO Port Space",
+	"PAL Code"
+};
+
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+				     const efi_memory_desc_t *md)
+{
+	char *pos;
+	int type_len;
+	register u64 attr;
+
+	pos = buf;
+	if (md->type >= ARRAY_SIZE(memory_type_name))
+		type_len = snprintf(pos, size, "[type=%u", md->type);
+	else
+		type_len = snprintf(pos, size, "[%-*s",
+				    (int)(sizeof(memory_type_name[0]) - 1),
+				    memory_type_name[md->type]);
+	if (type_len >= size)
+		return buf;
+
+	pos += type_len;
+	size -= type_len;
+
+	attr = md->attribute;
+	if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
+		     EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_WP |
+		     EFI_MEMORY_RP | EFI_MEMORY_XP | EFI_MEMORY_RUNTIME))
+		snprintf(pos, size, "|attr=0x%016llx]",
+			 (unsigned long long)attr);
+	else
+		snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
+			 attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
+			 attr & EFI_MEMORY_XP      ? "XP"  : "",
+			 attr & EFI_MEMORY_RP      ? "RP"  : "",
+			 attr & EFI_MEMORY_WP      ? "WP"  : "",
+			 attr & EFI_MEMORY_UCE     ? "UCE" : "",
+			 attr & EFI_MEMORY_WB      ? "WB"  : "",
+			 attr & EFI_MEMORY_WT      ? "WT"  : "",
+			 attr & EFI_MEMORY_WC      ? "WC"  : "",
+			 attr & EFI_MEMORY_UC      ? "UC"  : "");
+	return buf;
+}
-- 
1.8.3.1

[PATCH v2 2/5] efi: introduce efi_md_typeattr_format()

[Laszlo Ersek]

At the moment, there are three architectures debug-printing the EFI memory
map at initialization: x86, ia64, and arm64. They all use different format
strings, plus the EFI memory type and the EFI memory attributes are
similarly hard to decode for a human reader.

Introduce a helper __init function that formats the memory type and the
memory attributes in a unified way, to a user-provided character buffer.

The array "memory_type_name" is copied from the arm64 code, temporarily
duplicating it. The (otherwise optional) braces around each string literal
in the initializer list are dropped in order to match the kernel coding
style more closely. The element size is tightened from 32 to 20 bytes
(maximum actual string length + 1) so that we can derive the field width
from the element size.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 include/linux/efi.h        |  7 ++++++
 drivers/firmware/efi/efi.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index b4b1d8d..d04d618 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -887,6 +887,13 @@ extern bool efi_poweroff_required(void);
 	     (md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \
 	     (md) = (void *)(md) + (m)->desc_size)
 
+/*
+ * Format an EFI memory descriptor's type and attributes to a user-provided
+ * character buffer, as per snprintf(), and return the buffer.
+ */
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+				     const efi_memory_desc_t *md);
+
 /**
  * efi_range_is_wc - check the WC bit on an address range
  * @start: starting kvirt address
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 64ecbb5..43d9d25 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -423,3 +423,60 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose)
 	return ret;
 }
 #endif /* CONFIG_EFI_PARAMS_FROM_FDT */
+
+static __initdata char memory_type_name[][20] = {
+	"Reserved",
+	"Loader Code",
+	"Loader Data",
+	"Boot Code",
+	"Boot Data",
+	"Runtime Code",
+	"Runtime Data",
+	"Conventional Memory",
+	"Unusable Memory",
+	"ACPI Reclaim Memory",
+	"ACPI Memory NVS",
+	"Memory Mapped I/O",
+	"MMIO Port Space",
+	"PAL Code"
+};
+
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+				     const efi_memory_desc_t *md)
+{
+	char *pos;
+	int type_len;
+	register u64 attr;
+
+	pos = buf;
+	if (md->type >= ARRAY_SIZE(memory_type_name))
+		type_len = snprintf(pos, size, "[type=%u", md->type);
+	else
+		type_len = snprintf(pos, size, "[%-*s",
+				    (int)(sizeof(memory_type_name[0]) - 1),
+				    memory_type_name[md->type]);
+	if (type_len >= size)
+		return buf;
+
+	pos += type_len;
+	size -= type_len;
+
+	attr = md->attribute;
+	if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
+		     EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_WP |
+		     EFI_MEMORY_RP | EFI_MEMORY_XP | EFI_MEMORY_RUNTIME))
+		snprintf(pos, size, "|attr=0x%016llx]",
+			 (unsigned long long)attr);
+	else
+		snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
+			 attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
+			 attr & EFI_MEMORY_XP      ? "XP"  : "",
+			 attr & EFI_MEMORY_RP      ? "RP"  : "",
+			 attr & EFI_MEMORY_WP      ? "WP"  : "",
+			 attr & EFI_MEMORY_UCE     ? "UCE" : "",
+			 attr & EFI_MEMORY_WB      ? "WB"  : "",
+			 attr & EFI_MEMORY_WT      ? "WT"  : "",
+			 attr & EFI_MEMORY_WC      ? "WC"  : "",
+			 attr & EFI_MEMORY_UC      ? "UC"  : "");
+	return buf;
+}
-- 
1.8.3.1

[PATCH v2 2/5] efi: introduce efi_md_typeattr_format()

[Laszlo Ersek]

At the moment, there are three architectures debug-printing the EFI memory
map at initialization: x86, ia64, and arm64. They all use different format
strings, plus the EFI memory type and the EFI memory attributes are
similarly hard to decode for a human reader.

Introduce a helper __init function that formats the memory type and the
memory attributes in a unified way, to a user-provided character buffer.

The array "memory_type_name" is copied from the arm64 code, temporarily
duplicating it. The (otherwise optional) braces around each string literal
in the initializer list are dropped in order to match the kernel coding
style more closely. The element size is tightened from 32 to 20 bytes
(maximum actual string length + 1) so that we can derive the field width
from the element size.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 include/linux/efi.h        |  7 ++++++
 drivers/firmware/efi/efi.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/include/linux/efi.h b/include/linux/efi.h
index b4b1d8d..d04d618 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -887,6 +887,13 @@ extern bool efi_poweroff_required(void);
 	     (md) <= (efi_memory_desc_t *)((m)->map_end - (m)->desc_size); \
 	     (md) = (void *)(md) + (m)->desc_size)
 
+/*
+ * Format an EFI memory descriptor's type and attributes to a user-provided
+ * character buffer, as per snprintf(), and return the buffer.
+ */
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+				     const efi_memory_desc_t *md);
+
 /**
  * efi_range_is_wc - check the WC bit on an address range
  * @start: starting kvirt address
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 64ecbb5..43d9d25 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -423,3 +423,60 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params, int verbose)
 	return ret;
 }
 #endif /* CONFIG_EFI_PARAMS_FROM_FDT */
+
+static __initdata char memory_type_name[][20] = {
+	"Reserved",
+	"Loader Code",
+	"Loader Data",
+	"Boot Code",
+	"Boot Data",
+	"Runtime Code",
+	"Runtime Data",
+	"Conventional Memory",
+	"Unusable Memory",
+	"ACPI Reclaim Memory",
+	"ACPI Memory NVS",
+	"Memory Mapped I/O",
+	"MMIO Port Space",
+	"PAL Code"
+};
+
+char * __init efi_md_typeattr_format(char *buf, size_t size,
+				     const efi_memory_desc_t *md)
+{
+	char *pos;
+	int type_len;
+	register u64 attr;
+
+	pos = buf;
+	if (md->type >= ARRAY_SIZE(memory_type_name))
+		type_len = snprintf(pos, size, "[type=%u", md->type);
+	else
+		type_len = snprintf(pos, size, "[%-*s",
+				    (int)(sizeof(memory_type_name[0]) - 1),
+				    memory_type_name[md->type]);
+	if (type_len >= size)
+		return buf;
+
+	pos += type_len;
+	size -= type_len;
+
+	attr = md->attribute;
+	if (attr & ~(EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
+		     EFI_MEMORY_WB | EFI_MEMORY_UCE | EFI_MEMORY_WP |
+		     EFI_MEMORY_RP | EFI_MEMORY_XP | EFI_MEMORY_RUNTIME))
+		snprintf(pos, size, "|attr=0x%016llx]",
+			 (unsigned long long)attr);
+	else
+		snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
+			 attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
+			 attr & EFI_MEMORY_XP      ? "XP"  : "",
+			 attr & EFI_MEMORY_RP      ? "RP"  : "",
+			 attr & EFI_MEMORY_WP      ? "WP"  : "",
+			 attr & EFI_MEMORY_UCE     ? "UCE" : "",
+			 attr & EFI_MEMORY_WB      ? "WB"  : "",
+			 attr & EFI_MEMORY_WT      ? "WT"  : "",
+			 attr & EFI_MEMORY_WC      ? "WC"  : "",
+			 attr & EFI_MEMORY_UC      ? "UC"  : "");
+	return buf;
+}
-- 
1.8.3.1

[PATCH v2 3/5] x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

An example log excerpt demonstrating the change:

Before the patch:

> efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: type=2, attr=0xf, range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: type=7, attr=0xf, range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: type=2, attr=0xf, range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: type=10, attr=0xf, range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: type=7, attr=0xf, range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: type=10, attr=0xf, range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: type=4, attr=0xf, range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: type=7, attr=0xf, range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: type=2, attr=0xf, range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: type=7, attr=0xf, range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: type=4, attr=0xf, range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: type=7, attr=0xf, range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: type=2, attr=0xf, range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: type=3, attr=0xf, range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: type=6, attr=0x800000000000000f, range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: type=5, attr=0x800000000000000f, range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: type=6, attr=0x800000000000000f, range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: type=3, attr=0xf, range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: type=6, attr=0x800000000000000f, range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: type=10, attr=0xf, range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: type=6, attr=0x800000000000000f, range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: type=5, attr=0x800000000000000f, range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: type=7, attr=0xf, range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: type=4, attr=0xf, range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: type=7, attr=0xf, range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: type=3, attr=0xf, range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: type=5, attr=0x800000000000000f, range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: type=6, attr=0x800000000000000f, range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: type=7, attr=0xf, range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: type=9, attr=0xf, range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: type=10, attr=0xf, range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: type=4, attr=0xf, range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: type=6, attr=0x800000000000000f, range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: type=7, attr=0xf, range=[0x0000000007ff0000-0x0000000008000000) (0MB)

After the patch:

> efi: mem00: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: [ACPI Reclaim Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ff0000-0x0000000008000000) (0MB)

Both the type enum and the attribute bitmap are decoded, with the
additional benefit that the memory ranges line up as well.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/x86/platform/efi/efi.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 850da94..ae2573a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -210,9 +210,12 @@ static void __init print_efi_memmap(void)
 	for (p = memmap.map, i = 0;
 	     p < memmap.map_end;
 	     p += memmap.desc_size, i++) {
+		char buf[64];
+
 		md = p;
-		pr_info("mem%02u: type=%u, attr=0x%llx, range=[0x%016llx-0x%016llx) (%lluMB)\n",
-			i, md->type, md->attribute, md->phys_addr,
+		pr_info("mem%02u: %s range=[0x%016llx-0x%016llx) (%lluMB)\n",
+			i, efi_md_typeattr_format(buf, sizeof(buf), md),
+			md->phys_addr,
 			md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
 			(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
 	}
-- 
1.8.3.1

[PATCH v2 3/5] x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

An example log excerpt demonstrating the change:

Before the patch:

> efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: type=2, attr=0xf, range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: type=7, attr=0xf, range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: type=2, attr=0xf, range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: type=10, attr=0xf, range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: type=7, attr=0xf, range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: type=10, attr=0xf, range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: type=4, attr=0xf, range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: type=7, attr=0xf, range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: type=2, attr=0xf, range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: type=7, attr=0xf, range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: type=4, attr=0xf, range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: type=7, attr=0xf, range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: type=2, attr=0xf, range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: type=3, attr=0xf, range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: type=6, attr=0x800000000000000f, range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: type=5, attr=0x800000000000000f, range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: type=6, attr=0x800000000000000f, range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: type=3, attr=0xf, range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: type=6, attr=0x800000000000000f, range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: type=10, attr=0xf, range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: type=6, attr=0x800000000000000f, range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: type=5, attr=0x800000000000000f, range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: type=7, attr=0xf, range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: type=4, attr=0xf, range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: type=7, attr=0xf, range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: type=3, attr=0xf, range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: type=5, attr=0x800000000000000f, range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: type=6, attr=0x800000000000000f, range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: type=7, attr=0xf, range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: type=9, attr=0xf, range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: type=10, attr=0xf, range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: type=4, attr=0xf, range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: type=6, attr=0x800000000000000f, range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: type=7, attr=0xf, range=[0x0000000007ff0000-0x0000000008000000) (0MB)

After the patch:

> efi: mem00: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: [ACPI Reclaim Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ff0000-0x0000000008000000) (0MB)

Both the type enum and the attribute bitmap are decoded, with the
additional benefit that the memory ranges line up as well.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/x86/platform/efi/efi.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 850da94..ae2573a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -210,9 +210,12 @@ static void __init print_efi_memmap(void)
 	for (p = memmap.map, i = 0;
 	     p < memmap.map_end;
 	     p += memmap.desc_size, i++) {
+		char buf[64];
+
 		md = p;
-		pr_info("mem%02u: type=%u, attr=0x%llx, range=[0x%016llx-0x%016llx) (%lluMB)\n",
-			i, md->type, md->attribute, md->phys_addr,
+		pr_info("mem%02u: %s range=[0x%016llx-0x%016llx) (%lluMB)\n",
+			i, efi_md_typeattr_format(buf, sizeof(buf), md),
+			md->phys_addr,
 			md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
 			(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
 	}
-- 
1.8.3.1

[PATCH v2 3/5] x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

An example log excerpt demonstrating the change:

Before the patch:

> efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: type=2, attr=0xf, range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: type=7, attr=0xf, range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: type=2, attr=0xf, range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: type\x10, attr=0xf, range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: type=7, attr=0xf, range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: type\x10, attr=0xf, range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: type=4, attr=0xf, range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: type=7, attr=0xf, range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: type=2, attr=0xf, range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: type=7, attr=0xf, range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: type=4, attr=0xf, range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: type=7, attr=0xf, range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: type=2, attr=0xf, range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: type=3, attr=0xf, range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: type=6, attr=0x800000000000000f, range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: type=5, attr=0x800000000000000f, range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: type=6, attr=0x800000000000000f, range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: type=3, attr=0xf, range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: type=6, attr=0x800000000000000f, range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: type\x10, attr=0xf, range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: type=6, attr=0x800000000000000f, range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: type=5, attr=0x800000000000000f, range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: type=7, attr=0xf, range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: type=4, attr=0xf, range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: type=7, attr=0xf, range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: type=3, attr=0xf, range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: type=5, attr=0x800000000000000f, range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: type=6, attr=0x800000000000000f, range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: type=7, attr=0xf, range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: type=9, attr=0xf, range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: type\x10, attr=0xf, range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: type=4, attr=0xf, range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: type=6, attr=0x800000000000000f, range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: type=7, attr=0xf, range=[0x0000000007ff0000-0x0000000008000000) (0MB)

After the patch:

> efi: mem00: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000000000-0x000000000009f000) (0MB)
> efi: mem01: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x000000000009f000-0x00000000000a0000) (0MB)
> efi: mem02: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000100000-0x0000000000400000) (3MB)
> efi: mem03: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000400000-0x0000000000800000) (4MB)
> efi: mem04: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000800000-0x0000000000808000) (0MB)
> efi: mem05: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000808000-0x0000000000810000) (0MB)
> efi: mem06: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000810000-0x0000000000900000) (0MB)
> efi: mem07: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000900000-0x0000000001100000) (8MB)
> efi: mem08: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000001100000-0x0000000001400000) (3MB)
> efi: mem09: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000001400000-0x0000000002613000) (18MB)
> efi: mem10: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000002613000-0x0000000004000000) (25MB)
> efi: mem11: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000004000000-0x0000000004020000) (0MB)
> efi: mem12: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000004020000-0x00000000068ea000) (40MB)
> efi: mem13: [Loader Data        |   |  |  |  |   |WB|WT|WC|UC] range=[0x00000000068ea000-0x00000000068f0000) (0MB)
> efi: mem14: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x00000000068f0000-0x0000000006c7b000) (3MB)
> efi: mem15: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c7b000-0x0000000006c7d000) (0MB)
> efi: mem16: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c7d000-0x0000000006c85000) (0MB)
> efi: mem17: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c85000-0x0000000006c87000) (0MB)
> efi: mem18: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006c87000-0x0000000006ca3000) (0MB)
> efi: mem19: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006ca3000-0x0000000006ca6000) (0MB)
> efi: mem20: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006ca6000-0x0000000006cc6000) (0MB)
> efi: mem21: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006cc6000-0x0000000006d95000) (0MB)
> efi: mem22: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000006d95000-0x0000000006e22000) (0MB)
> efi: mem23: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000006e22000-0x0000000007165000) (3MB)
> efi: mem24: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007165000-0x0000000007d22000) (11MB)
> efi: mem25: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007d22000-0x0000000007d25000) (0MB)
> efi: mem26: [Boot Code          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007d25000-0x0000000007ea2000) (1MB)
> efi: mem27: [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ea2000-0x0000000007ed2000) (0MB)
> efi: mem28: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ed2000-0x0000000007ef6000) (0MB)
> efi: mem29: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ef6000-0x0000000007f00000) (0MB)
> efi: mem30: [ACPI Reclaim Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f00000-0x0000000007f02000) (0MB)
> efi: mem31: [ACPI Memory NVS    |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f02000-0x0000000007f06000) (0MB)
> efi: mem32: [Boot Data          |   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007f06000-0x0000000007fd0000) (0MB)
> efi: mem33: [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC] range=[0x0000000007fd0000-0x0000000007ff0000) (0MB)
> efi: mem34: [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC] range=[0x0000000007ff0000-0x0000000008000000) (0MB)

Both the type enum and the attribute bitmap are decoded, with the
additional benefit that the memory ranges line up as well.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/x86/platform/efi/efi.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 850da94..ae2573a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -210,9 +210,12 @@ static void __init print_efi_memmap(void)
 	for (p = memmap.map, i = 0;
 	     p < memmap.map_end;
 	     p += memmap.desc_size, i++) {
+		char buf[64];
+
 		md = p;
-		pr_info("mem%02u: type=%u, attr=0x%llx, range=[0x%016llx-0x%016llx) (%lluMB)\n",
-			i, md->type, md->attribute, md->phys_addr,
+		pr_info("mem%02u: %s range=[0x%016llx-0x%016llx) (%lluMB)\n",
+			i, efi_md_typeattr_format(buf, sizeof(buf), md),
+			md->phys_addr,
 			md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
 			(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
 	}
-- 
1.8.3.1

[PATCH v2 4/5] ia64: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

The effects of the patch on the i64 memory map log are similar to those
visible in the previous (x86) patch: the type enum and the attribute
bitmap are decoded.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/ia64/kernel/efi.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 741b99c..c52d754 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -568,6 +568,7 @@ efi_init (void)
 		{
 			const char *unit;
 			unsigned long size;
+			char buf[64];
 
 			md = p;
 			size = md->num_pages << EFI_PAGE_SHIFT;
@@ -586,9 +587,10 @@ efi_init (void)
 				unit = "KB";
 			}
 
-			printk("mem%02d: type=%2u, attr=0x%016lx, "
+			printk("mem%02d: %s "
 			       "range=[0x%016lx-0x%016lx) (%4lu%s)\n",
-			       i, md->type, md->attribute, md->phys_addr,
+			       i, efi_md_typeattr_format(buf, sizeof(buf), md),
+			       md->phys_addr,
 			       md->phys_addr + efi_md_size(md), size, unit);
 		}
 	}
-- 
1.8.3.1

[PATCH v2 4/5] ia64: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

The effects of the patch on the i64 memory map log are similar to those
visible in the previous (x86) patch: the type enum and the attribute
bitmap are decoded.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/ia64/kernel/efi.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 741b99c..c52d754 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -568,6 +568,7 @@ efi_init (void)
 		{
 			const char *unit;
 			unsigned long size;
+			char buf[64];
 
 			md = p;
 			size = md->num_pages << EFI_PAGE_SHIFT;
@@ -586,9 +587,10 @@ efi_init (void)
 				unit = "KB";
 			}
 
-			printk("mem%02d: type=%2u, attr=0x%016lx, "
+			printk("mem%02d: %s "
 			       "range=[0x%016lx-0x%016lx) (%4lu%s)\n",
-			       i, md->type, md->attribute, md->phys_addr,
+			       i, efi_md_typeattr_format(buf, sizeof(buf), md),
+			       md->phys_addr,
 			       md->phys_addr + efi_md_size(md), size, unit);
 		}
 	}
-- 
1.8.3.1

[PATCH v2 4/5] ia64: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

The effects of the patch on the i64 memory map log are similar to those
visible in the previous (x86) patch: the type enum and the attribute
bitmap are decoded.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/ia64/kernel/efi.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 741b99c..c52d754 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -568,6 +568,7 @@ efi_init (void)
 		{
 			const char *unit;
 			unsigned long size;
+			char buf[64];
 
 			md = p;
 			size = md->num_pages << EFI_PAGE_SHIFT;
@@ -586,9 +587,10 @@ efi_init (void)
 				unit = "KB";
 			}
 
-			printk("mem%02d: type=%2u, attr=0x%016lx, "
+			printk("mem%02d: %s "
 			       "range=[0x%016lx-0x%016lx) (%4lu%s)\n",
-			       i, md->type, md->attribute, md->phys_addr,
+			       i, efi_md_typeattr_format(buf, sizeof(buf), md),
+			       md->phys_addr,
 			       md->phys_addr + efi_md_size(md), size, unit);
 		}
 	}
-- 
1.8.3.1

[PATCH v2 5/5] arm64: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

An example log excerpt demonstrating the change:

Before the patch:

> Processing EFI memory map:
>   0x000040000000-0x000040000fff [Loader Data]
>   0x000040001000-0x00004007ffff [Conventional Memory]
>   0x000040080000-0x00004072afff [Loader Data]
>   0x00004072b000-0x00005fdfffff [Conventional Memory]
>   0x00005fe00000-0x00005fe0ffff [Loader Data]
>   0x00005fe10000-0x0000964e8fff [Conventional Memory]
>   0x0000964e9000-0x0000964e9fff [Loader Data]
>   0x0000964ea000-0x000096c52fff [Loader Code]
>   0x000096c53000-0x00009709dfff [Boot Code]*
>   0x00009709e000-0x0000970b3fff [Runtime Code]*
>   0x0000970b4000-0x0000970f4fff [Runtime Data]*
>   0x0000970f5000-0x000097117fff [Runtime Code]*
>   0x000097118000-0x000097199fff [Runtime Data]*
>   0x00009719a000-0x0000971dffff [Runtime Code]*
>   0x0000971e0000-0x0000997f8fff [Conventional Memory]
>   0x0000997f9000-0x0000998f1fff [Boot Data]*
>   0x0000998f2000-0x0000999eafff [Conventional Memory]
>   0x0000999eb000-0x00009af09fff [Boot Data]*
>   0x00009af0a000-0x00009af21fff [Conventional Memory]
>   0x00009af22000-0x00009af46fff [Boot Data]*
>   0x00009af47000-0x00009af5bfff [Conventional Memory]
>   0x00009af5c000-0x00009afe1fff [Boot Data]*
>   0x00009afe2000-0x00009afe2fff [Conventional Memory]
>   0x00009afe3000-0x00009c01ffff [Boot Data]*
>   0x00009c020000-0x00009efbffff [Conventional Memory]
>   0x00009efc0000-0x00009f14efff [Boot Code]*
>   0x00009f14f000-0x00009f162fff [Runtime Code]*
>   0x00009f163000-0x00009f194fff [Runtime Data]*
>   0x00009f195000-0x00009f197fff [Boot Data]*
>   0x00009f198000-0x00009f198fff [Runtime Data]*
>   0x00009f199000-0x00009f1acfff [Conventional Memory]
>   0x00009f1ad000-0x00009f1affff [Boot Data]*
>   0x00009f1b0000-0x00009f1b0fff [Runtime Data]*
>   0x00009f1b1000-0x00009fffffff [Boot Data]*
>   0x000004000000-0x000007ffffff [Memory Mapped I/O]
>   0x000009010000-0x000009010fff [Memory Mapped I/O]

After the patch:

> Processing EFI memory map:
>   0x000040000000-0x000040000fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x000040001000-0x00004007ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x000040080000-0x00004072afff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x00004072b000-0x00005fdfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00005fe00000-0x00005fe0ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x00005fe10000-0x0000964e8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000964e9000-0x0000964e9fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x0000964ea000-0x000096c52fff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
>   0x000096c53000-0x00009709dfff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009709e000-0x0000970b3fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000970b4000-0x0000970f4fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000970f5000-0x000097117fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x000097118000-0x000097199fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009719a000-0x0000971dffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000971e0000-0x0000997f8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000997f9000-0x0000998f1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x0000998f2000-0x0000999eafff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000999eb000-0x00009af09fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009af0a000-0x00009af21fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009af22000-0x00009af46fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009af47000-0x00009af5bfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009af5c000-0x00009afe1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009afe2000-0x00009afe2fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009afe3000-0x00009c01ffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009c020000-0x00009efbffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009efc0000-0x00009f14efff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f14f000-0x00009f162fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f163000-0x00009f194fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f195000-0x00009f197fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f198000-0x00009f198fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f199000-0x00009f1acfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009f1ad000-0x00009f1affff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f1b0000-0x00009f1b0fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f1b1000-0x00009fffffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x000004000000-0x000007ffffff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
>   0x000009010000-0x000009010fff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]

The attribute bitmap is now displayed, in decoded form.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/arm64/kernel/efi.c | 26 ++++++--------------------
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 03aaa99..3b1f23c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -119,23 +119,6 @@ static int __init uefi_init(void)
 	return retval;
 }
 
-static __initdata char memory_type_name[][32] = {
-	{"Reserved"},
-	{"Loader Code"},
-	{"Loader Data"},
-	{"Boot Code"},
-	{"Boot Data"},
-	{"Runtime Code"},
-	{"Runtime Data"},
-	{"Conventional Memory"},
-	{"Unusable Memory"},
-	{"ACPI Reclaim Memory"},
-	{"ACPI Memory NVS"},
-	{"Memory Mapped I/O"},
-	{"MMIO Port Space"},
-	{"PAL Code"},
-};
-
 /*
  * Return true for RAM regions we want to permanently reserve.
  */
@@ -166,10 +149,13 @@ static __init void reserve_regions(void)
 		paddr = md->phys_addr;
 		npages = md->num_pages;
 
-		if (uefi_debug)
-			pr_info("  0x%012llx-0x%012llx [%s]",
+		if (uefi_debug) {
+			char buf[64];
+
+			pr_info("  0x%012llx-0x%012llx %s",
 				paddr, paddr + (npages << EFI_PAGE_SHIFT) - 1,
-				memory_type_name[md->type]);
+				efi_md_typeattr_format(buf, sizeof(buf), md));
+		}
 
 		memrange_efi_to_native(&paddr, &npages);
 		size = npages << PAGE_SHIFT;
-- 
1.8.3.1

[PATCH v2 5/5] arm64: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

An example log excerpt demonstrating the change:

Before the patch:

> Processing EFI memory map:
>   0x000040000000-0x000040000fff [Loader Data]
>   0x000040001000-0x00004007ffff [Conventional Memory]
>   0x000040080000-0x00004072afff [Loader Data]
>   0x00004072b000-0x00005fdfffff [Conventional Memory]
>   0x00005fe00000-0x00005fe0ffff [Loader Data]
>   0x00005fe10000-0x0000964e8fff [Conventional Memory]
>   0x0000964e9000-0x0000964e9fff [Loader Data]
>   0x0000964ea000-0x000096c52fff [Loader Code]
>   0x000096c53000-0x00009709dfff [Boot Code]*
>   0x00009709e000-0x0000970b3fff [Runtime Code]*
>   0x0000970b4000-0x0000970f4fff [Runtime Data]*
>   0x0000970f5000-0x000097117fff [Runtime Code]*
>   0x000097118000-0x000097199fff [Runtime Data]*
>   0x00009719a000-0x0000971dffff [Runtime Code]*
>   0x0000971e0000-0x0000997f8fff [Conventional Memory]
>   0x0000997f9000-0x0000998f1fff [Boot Data]*
>   0x0000998f2000-0x0000999eafff [Conventional Memory]
>   0x0000999eb000-0x00009af09fff [Boot Data]*
>   0x00009af0a000-0x00009af21fff [Conventional Memory]
>   0x00009af22000-0x00009af46fff [Boot Data]*
>   0x00009af47000-0x00009af5bfff [Conventional Memory]
>   0x00009af5c000-0x00009afe1fff [Boot Data]*
>   0x00009afe2000-0x00009afe2fff [Conventional Memory]
>   0x00009afe3000-0x00009c01ffff [Boot Data]*
>   0x00009c020000-0x00009efbffff [Conventional Memory]
>   0x00009efc0000-0x00009f14efff [Boot Code]*
>   0x00009f14f000-0x00009f162fff [Runtime Code]*
>   0x00009f163000-0x00009f194fff [Runtime Data]*
>   0x00009f195000-0x00009f197fff [Boot Data]*
>   0x00009f198000-0x00009f198fff [Runtime Data]*
>   0x00009f199000-0x00009f1acfff [Conventional Memory]
>   0x00009f1ad000-0x00009f1affff [Boot Data]*
>   0x00009f1b0000-0x00009f1b0fff [Runtime Data]*
>   0x00009f1b1000-0x00009fffffff [Boot Data]*
>   0x000004000000-0x000007ffffff [Memory Mapped I/O]
>   0x000009010000-0x000009010fff [Memory Mapped I/O]

After the patch:

> Processing EFI memory map:
>   0x000040000000-0x000040000fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x000040001000-0x00004007ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x000040080000-0x00004072afff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x00004072b000-0x00005fdfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00005fe00000-0x00005fe0ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x00005fe10000-0x0000964e8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000964e9000-0x0000964e9fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x0000964ea000-0x000096c52fff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
>   0x000096c53000-0x00009709dfff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009709e000-0x0000970b3fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000970b4000-0x0000970f4fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000970f5000-0x000097117fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x000097118000-0x000097199fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009719a000-0x0000971dffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000971e0000-0x0000997f8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000997f9000-0x0000998f1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x0000998f2000-0x0000999eafff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000999eb000-0x00009af09fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009af0a000-0x00009af21fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009af22000-0x00009af46fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009af47000-0x00009af5bfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009af5c000-0x00009afe1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009afe2000-0x00009afe2fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009afe3000-0x00009c01ffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009c020000-0x00009efbffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009efc0000-0x00009f14efff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f14f000-0x00009f162fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f163000-0x00009f194fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f195000-0x00009f197fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f198000-0x00009f198fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f199000-0x00009f1acfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009f1ad000-0x00009f1affff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f1b0000-0x00009f1b0fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f1b1000-0x00009fffffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x000004000000-0x000007ffffff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
>   0x000009010000-0x000009010fff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]

The attribute bitmap is now displayed, in decoded form.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/arm64/kernel/efi.c | 26 ++++++--------------------
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 03aaa99..3b1f23c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -119,23 +119,6 @@ static int __init uefi_init(void)
 	return retval;
 }
 
-static __initdata char memory_type_name[][32] = {
-	{"Reserved"},
-	{"Loader Code"},
-	{"Loader Data"},
-	{"Boot Code"},
-	{"Boot Data"},
-	{"Runtime Code"},
-	{"Runtime Data"},
-	{"Conventional Memory"},
-	{"Unusable Memory"},
-	{"ACPI Reclaim Memory"},
-	{"ACPI Memory NVS"},
-	{"Memory Mapped I/O"},
-	{"MMIO Port Space"},
-	{"PAL Code"},
-};
-
 /*
  * Return true for RAM regions we want to permanently reserve.
  */
@@ -166,10 +149,13 @@ static __init void reserve_regions(void)
 		paddr = md->phys_addr;
 		npages = md->num_pages;
 
-		if (uefi_debug)
-			pr_info("  0x%012llx-0x%012llx [%s]",
+		if (uefi_debug) {
+			char buf[64];
+
+			pr_info("  0x%012llx-0x%012llx %s",
 				paddr, paddr + (npages << EFI_PAGE_SHIFT) - 1,
-				memory_type_name[md->type]);
+				efi_md_typeattr_format(buf, sizeof(buf), md));
+		}
 
 		memrange_efi_to_native(&paddr, &npages);
 		size = npages << PAGE_SHIFT;
-- 
1.8.3.1

[PATCH v2 5/5] arm64: efi: format EFI memory type & attrs with efi_md_typeattr_format()

[Laszlo Ersek]

An example log excerpt demonstrating the change:

Before the patch:

> Processing EFI memory map:
>   0x000040000000-0x000040000fff [Loader Data]
>   0x000040001000-0x00004007ffff [Conventional Memory]
>   0x000040080000-0x00004072afff [Loader Data]
>   0x00004072b000-0x00005fdfffff [Conventional Memory]
>   0x00005fe00000-0x00005fe0ffff [Loader Data]
>   0x00005fe10000-0x0000964e8fff [Conventional Memory]
>   0x0000964e9000-0x0000964e9fff [Loader Data]
>   0x0000964ea000-0x000096c52fff [Loader Code]
>   0x000096c53000-0x00009709dfff [Boot Code]*
>   0x00009709e000-0x0000970b3fff [Runtime Code]*
>   0x0000970b4000-0x0000970f4fff [Runtime Data]*
>   0x0000970f5000-0x000097117fff [Runtime Code]*
>   0x000097118000-0x000097199fff [Runtime Data]*
>   0x00009719a000-0x0000971dffff [Runtime Code]*
>   0x0000971e0000-0x0000997f8fff [Conventional Memory]
>   0x0000997f9000-0x0000998f1fff [Boot Data]*
>   0x0000998f2000-0x0000999eafff [Conventional Memory]
>   0x0000999eb000-0x00009af09fff [Boot Data]*
>   0x00009af0a000-0x00009af21fff [Conventional Memory]
>   0x00009af22000-0x00009af46fff [Boot Data]*
>   0x00009af47000-0x00009af5bfff [Conventional Memory]
>   0x00009af5c000-0x00009afe1fff [Boot Data]*
>   0x00009afe2000-0x00009afe2fff [Conventional Memory]
>   0x00009afe3000-0x00009c01ffff [Boot Data]*
>   0x00009c020000-0x00009efbffff [Conventional Memory]
>   0x00009efc0000-0x00009f14efff [Boot Code]*
>   0x00009f14f000-0x00009f162fff [Runtime Code]*
>   0x00009f163000-0x00009f194fff [Runtime Data]*
>   0x00009f195000-0x00009f197fff [Boot Data]*
>   0x00009f198000-0x00009f198fff [Runtime Data]*
>   0x00009f199000-0x00009f1acfff [Conventional Memory]
>   0x00009f1ad000-0x00009f1affff [Boot Data]*
>   0x00009f1b0000-0x00009f1b0fff [Runtime Data]*
>   0x00009f1b1000-0x00009fffffff [Boot Data]*
>   0x000004000000-0x000007ffffff [Memory Mapped I/O]
>   0x000009010000-0x000009010fff [Memory Mapped I/O]

After the patch:

> Processing EFI memory map:
>   0x000040000000-0x000040000fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x000040001000-0x00004007ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x000040080000-0x00004072afff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x00004072b000-0x00005fdfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00005fe00000-0x00005fe0ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x00005fe10000-0x0000964e8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000964e9000-0x0000964e9fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>   0x0000964ea000-0x000096c52fff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
>   0x000096c53000-0x00009709dfff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009709e000-0x0000970b3fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000970b4000-0x0000970f4fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000970f5000-0x000097117fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x000097118000-0x000097199fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009719a000-0x0000971dffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x0000971e0000-0x0000997f8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000997f9000-0x0000998f1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x0000998f2000-0x0000999eafff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x0000999eb000-0x00009af09fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009af0a000-0x00009af21fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009af22000-0x00009af46fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009af47000-0x00009af5bfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009af5c000-0x00009afe1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009afe2000-0x00009afe2fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009afe3000-0x00009c01ffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009c020000-0x00009efbffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009efc0000-0x00009f14efff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f14f000-0x00009f162fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f163000-0x00009f194fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f195000-0x00009f197fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f198000-0x00009f198fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f199000-0x00009f1acfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>   0x00009f1ad000-0x00009f1affff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x00009f1b0000-0x00009f1b0fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>   0x00009f1b1000-0x00009fffffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
>   0x000004000000-0x000007ffffff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
>   0x000009010000-0x000009010fff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]

The attribute bitmap is now displayed, in decoded form.

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 arch/arm64/kernel/efi.c | 26 ++++++--------------------
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 03aaa99..3b1f23c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -119,23 +119,6 @@ static int __init uefi_init(void)
 	return retval;
 }
 
-static __initdata char memory_type_name[][32] = {
-	{"Reserved"},
-	{"Loader Code"},
-	{"Loader Data"},
-	{"Boot Code"},
-	{"Boot Data"},
-	{"Runtime Code"},
-	{"Runtime Data"},
-	{"Conventional Memory"},
-	{"Unusable Memory"},
-	{"ACPI Reclaim Memory"},
-	{"ACPI Memory NVS"},
-	{"Memory Mapped I/O"},
-	{"MMIO Port Space"},
-	{"PAL Code"},
-};
-
 /*
  * Return true for RAM regions we want to permanently reserve.
  */
@@ -166,10 +149,13 @@ static __init void reserve_regions(void)
 		paddr = md->phys_addr;
 		npages = md->num_pages;
 
-		if (uefi_debug)
-			pr_info("  0x%012llx-0x%012llx [%s]",
+		if (uefi_debug) {
+			char buf[64];
+
+			pr_info("  0x%012llx-0x%012llx %s",
 				paddr, paddr + (npages << EFI_PAGE_SHIFT) - 1,
-				memory_type_name[md->type]);
+				efi_md_typeattr_format(buf, sizeof(buf), md));
+		}
 
 		memrange_efi_to_native(&paddr, &npages);
 		size = npages << PAGE_SHIFT;
-- 
1.8.3.1

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Ard Biesheuvel]

On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
> changes in v2:
> - explain with examples how the log's appearance changes, in patches 3-5
>   [Ingo]
>
> v1 blurb:
>
>> It's a pain to analyze EFI memmap logs while debugging, especially to
>> verify the memory types (an enum) and the memory attributes (a
>> bitmap). This series renders those columns human-readable, and unifies
>> their formatting between x86, ia64 and arm64.
>

Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
(on arm64 only)

+1 for aligning between architectures
+1 for cleaning up the output to make it more readable

The only thing I am not entirely convinced about is printing all those
memory attributes: is it really so interesting to know that region X
/can/ be configured as writeback, write through, write combining etc
etc, as most regions seem to support most attributes, yet it tells you
nothing about what the kernel ends up doing with that information. In
the arm64 case, for instance, all MEMORY_WB ranges are mapped
writeback cached, and everything else is mapped uncached.

-- 
Ard.


> Laszlo Ersek (5):
>   efi: add macro for EFI_MEMORY_UCE memory attribute
>   efi: introduce efi_md_typeattr_format()
>   x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
>   ia64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>   arm64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>
>  include/linux/efi.h         |  8 +++++++
>  arch/arm64/kernel/efi.c     | 26 +++++----------------
>  arch/ia64/kernel/efi.c      |  6 +++--
>  arch/x86/platform/efi/efi.c |  7 ++++--
>  drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 80 insertions(+), 24 deletions(-)
>
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Ard Biesheuvel]

On 3 September 2014 13:32, Laszlo Ersek <lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> changes in v2:
> - explain with examples how the log's appearance changes, in patches 3-5
>   [Ingo]
>
> v1 blurb:
>
>> It's a pain to analyze EFI memmap logs while debugging, especially to
>> verify the memory types (an enum) and the memory attributes (a
>> bitmap). This series renders those columns human-readable, and unifies
>> their formatting between x86, ia64 and arm64.
>

Tested-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
(on arm64 only)

+1 for aligning between architectures
+1 for cleaning up the output to make it more readable

The only thing I am not entirely convinced about is printing all those
memory attributes: is it really so interesting to know that region X
/can/ be configured as writeback, write through, write combining etc
etc, as most regions seem to support most attributes, yet it tells you
nothing about what the kernel ends up doing with that information. In
the arm64 case, for instance, all MEMORY_WB ranges are mapped
writeback cached, and everything else is mapped uncached.

-- 
Ard.


> Laszlo Ersek (5):
>   efi: add macro for EFI_MEMORY_UCE memory attribute
>   efi: introduce efi_md_typeattr_format()
>   x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
>   ia64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>   arm64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>
>  include/linux/efi.h         |  8 +++++++
>  arch/arm64/kernel/efi.c     | 26 +++++----------------
>  arch/ia64/kernel/efi.c      |  6 +++--
>  arch/x86/platform/efi/efi.c |  7 ++++--
>  drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 80 insertions(+), 24 deletions(-)
>
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 0/5] beautify EFI memmap logs

[Ard Biesheuvel]

On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
> changes in v2:
> - explain with examples how the log's appearance changes, in patches 3-5
>   [Ingo]
>
> v1 blurb:
>
>> It's a pain to analyze EFI memmap logs while debugging, especially to
>> verify the memory types (an enum) and the memory attributes (a
>> bitmap). This series renders those columns human-readable, and unifies
>> their formatting between x86, ia64 and arm64.
>

Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
(on arm64 only)

+1 for aligning between architectures
+1 for cleaning up the output to make it more readable

The only thing I am not entirely convinced about is printing all those
memory attributes: is it really so interesting to know that region X
/can/ be configured as writeback, write through, write combining etc
etc, as most regions seem to support most attributes, yet it tells you
nothing about what the kernel ends up doing with that information. In
the arm64 case, for instance, all MEMORY_WB ranges are mapped
writeback cached, and everything else is mapped uncached.

-- 
Ard.


> Laszlo Ersek (5):
>   efi: add macro for EFI_MEMORY_UCE memory attribute
>   efi: introduce efi_md_typeattr_format()
>   x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
>   ia64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>   arm64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>
>  include/linux/efi.h         |  8 +++++++
>  arch/arm64/kernel/efi.c     | 26 +++++----------------
>  arch/ia64/kernel/efi.c      |  6 +++--
>  arch/x86/platform/efi/efi.c |  7 ++++--
>  drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 80 insertions(+), 24 deletions(-)
>
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Ard Biesheuvel]

On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
> changes in v2:
> - explain with examples how the log's appearance changes, in patches 3-5
>   [Ingo]
>
> v1 blurb:
>
>> It's a pain to analyze EFI memmap logs while debugging, especially to
>> verify the memory types (an enum) and the memory attributes (a
>> bitmap). This series renders those columns human-readable, and unifies
>> their formatting between x86, ia64 and arm64.
>

Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
(on arm64 only)

+1 for aligning between architectures
+1 for cleaning up the output to make it more readable

The only thing I am not entirely convinced about is printing all those
memory attributes: is it really so interesting to know that region X
/can/ be configured as writeback, write through, write combining etc
etc, as most regions seem to support most attributes, yet it tells you
nothing about what the kernel ends up doing with that information. In
the arm64 case, for instance, all MEMORY_WB ranges are mapped
writeback cached, and everything else is mapped uncached.

-- 
Ard.


> Laszlo Ersek (5):
>   efi: add macro for EFI_MEMORY_UCE memory attribute
>   efi: introduce efi_md_typeattr_format()
>   x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
>   ia64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>   arm64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>
>  include/linux/efi.h         |  8 +++++++
>  arch/arm64/kernel/efi.c     | 26 +++++----------------
>  arch/ia64/kernel/efi.c      |  6 +++--
>  arch/x86/platform/efi/efi.c |  7 ++++--
>  drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 80 insertions(+), 24 deletions(-)
>
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Matt Fleming]

On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
> 
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> (on arm64 only)
> 
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
 
Thanks Ard.

> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.

Personally, I think it's good to get an unadulterated version of the
firmware memory map (for vicarious debugging) before the kernel has a
chance to mess with it.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Matt Fleming]

On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
> 
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> (on arm64 only)
> 
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
 
Thanks Ard.

> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.

Personally, I think it's good to get an unadulterated version of the
firmware memory map (for vicarious debugging) before the kernel has a
chance to mess with it.

-- 
Matt Fleming, Intel Open Source Technology Center

[PATCH v2 0/5] beautify EFI memmap logs

[Matt Fleming]

On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
> 
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> (on arm64 only)
> 
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
 
Thanks Ard.

> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.

Personally, I think it's good to get an unadulterated version of the
firmware memory map (for vicarious debugging) before the kernel has a
chance to mess with it.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Matt Fleming]

On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
> 
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> (on arm64 only)
> 
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
 
Thanks Ard.

> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.

Personally, I think it's good to get an unadulterated version of the
firmware memory map (for vicarious debugging) before the kernel has a
chance to mess with it.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

On 09/03/14 15:01, Ard Biesheuvel wrote:
> On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
>> changes in v2:
>> - explain with examples how the log's appearance changes, in patches 3-5
>>   [Ingo]
>>
>> v1 blurb:
>>
>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>> verify the memory types (an enum) and the memory attributes (a
>>> bitmap). This series renders those columns human-readable, and unifies
>>> their formatting between x86, ia64 and arm64.
>>
> 
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> (on arm64 only)
> 
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
> 
> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.

You don't need these attributes spelled out when you're not debugging.
In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
or don't pass uefi_debug=1 (on arm64).

When you're debugging however, you need every bit of info you can get.
For example, assume a tricky bug in exactly that part of the arm64 code
that you just described above. You'll be flip-flopping between the
kernel source and the original, pristine memory map dump. It's much
easier to ignore a few words / columns in the log (even: cut it out with
a script or interactively) than to read bitmaps in hex (or to decode
them in a script). I know because I grew to hate these hex-encoded
attributes and dec-encoded enum constants when I was developing S3 for
OVMF, and fighting the memmap.

A good analogue is ACPI debugging in the kernel. The ACPI subsystem
comes with a very elaborate heap of switches, facility bitmaps, log
levels, and so on. The end result is that it is faster to add printks to
your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
to use the acpi debug flags. (And I did the former when I was recently
fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)

So yes, I think that this detailed format is preferable.

Thanks,
Laszlo

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

On 09/03/14 15:01, Ard Biesheuvel wrote:
> On 3 September 2014 13:32, Laszlo Ersek <lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> changes in v2:
>> - explain with examples how the log's appearance changes, in patches 3-5
>>   [Ingo]
>>
>> v1 blurb:
>>
>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>> verify the memory types (an enum) and the memory attributes (a
>>> bitmap). This series renders those columns human-readable, and unifies
>>> their formatting between x86, ia64 and arm64.
>>
> 
> Tested-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> (on arm64 only)
> 
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
> 
> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.

You don't need these attributes spelled out when you're not debugging.
In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
or don't pass uefi_debug=1 (on arm64).

When you're debugging however, you need every bit of info you can get.
For example, assume a tricky bug in exactly that part of the arm64 code
that you just described above. You'll be flip-flopping between the
kernel source and the original, pristine memory map dump. It's much
easier to ignore a few words / columns in the log (even: cut it out with
a script or interactively) than to read bitmaps in hex (or to decode
them in a script). I know because I grew to hate these hex-encoded
attributes and dec-encoded enum constants when I was developing S3 for
OVMF, and fighting the memmap.

A good analogue is ACPI debugging in the kernel. The ACPI subsystem
comes with a very elaborate heap of switches, facility bitmaps, log
levels, and so on. The end result is that it is faster to add printks to
your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
to use the acpi debug flags. (And I did the former when I was recently
fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)

So yes, I think that this detailed format is preferable.

Thanks,
Laszlo

[PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

On 09/03/14 15:01, Ard Biesheuvel wrote:
> On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
>> changes in v2:
>> - explain with examples how the log's appearance changes, in patches 3-5
>>   [Ingo]
>>
>> v1 blurb:
>>
>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>> verify the memory types (an enum) and the memory attributes (a
>>> bitmap). This series renders those columns human-readable, and unifies
>>> their formatting between x86, ia64 and arm64.
>>
> 
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> (on arm64 only)
> 
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
> 
> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.

You don't need these attributes spelled out when you're not debugging.
In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
or don't pass uefi_debug=1 (on arm64).

When you're debugging however, you need every bit of info you can get.
For example, assume a tricky bug in exactly that part of the arm64 code
that you just described above. You'll be flip-flopping between the
kernel source and the original, pristine memory map dump. It's much
easier to ignore a few words / columns in the log (even: cut it out with
a script or interactively) than to read bitmaps in hex (or to decode
them in a script). I know because I grew to hate these hex-encoded
attributes and dec-encoded enum constants when I was developing S3 for
OVMF, and fighting the memmap.

A good analogue is ACPI debugging in the kernel. The ACPI subsystem
comes with a very elaborate heap of switches, facility bitmaps, log
levels, and so on. The end result is that it is faster to add printks to
your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
to use the acpi debug flags. (And I did the former when I was recently
fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)

So yes, I think that this detailed format is preferable.

Thanks,
Laszlo

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

On 09/03/14 15:01, Ard Biesheuvel wrote:
> On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
>> changes in v2:
>> - explain with examples how the log's appearance changes, in patches 3-5
>>   [Ingo]
>>
>> v1 blurb:
>>
>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>> verify the memory types (an enum) and the memory attributes (a
>>> bitmap). This series renders those columns human-readable, and unifies
>>> their formatting between x86, ia64 and arm64.
>>
> 
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> (on arm64 only)
> 
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
> 
> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.

You don't need these attributes spelled out when you're not debugging.
In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
or don't pass uefi_debug=1 (on arm64).

When you're debugging however, you need every bit of info you can get.
For example, assume a tricky bug in exactly that part of the arm64 code
that you just described above. You'll be flip-flopping between the
kernel source and the original, pristine memory map dump. It's much
easier to ignore a few words / columns in the log (even: cut it out with
a script or interactively) than to read bitmaps in hex (or to decode
them in a script). I know because I grew to hate these hex-encoded
attributes and dec-encoded enum constants when I was developing S3 for
OVMF, and fighting the memmap.

A good analogue is ACPI debugging in the kernel. The ACPI subsystem
comes with a very elaborate heap of switches, facility bitmaps, log
levels, and so on. The end result is that it is faster to add printks to
your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
to use the acpi debug flags. (And I did the former when I was recently
fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)

So yes, I think that this detailed format is preferable.

Thanks,
Laszlo

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

On 09/03/14 15:18, Matt Fleming wrote:
> On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>  
> Thanks Ard.

Ah, apologies for forgetting to say thanks.

Thanks! :)
Laszlo

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

On 09/03/14 15:18, Matt Fleming wrote:
> On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>  
> Thanks Ard.

Ah, apologies for forgetting to say thanks.

Thanks! :)
Laszlo

[PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

On 09/03/14 15:18, Matt Fleming wrote:
> On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>  
> Thanks Ard.

Ah, apologies for forgetting to say thanks.

Thanks! :)
Laszlo

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Laszlo Ersek]

On 09/03/14 15:18, Matt Fleming wrote:
> On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>  
> Thanks Ard.

Ah, apologies for forgetting to say thanks.

Thanks! :)
Laszlo

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Ard Biesheuvel]

On 3 September 2014 15:24, Laszlo Ersek <lersek@redhat.com> wrote:
> On 09/03/14 15:01, Ard Biesheuvel wrote:
>> On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
>>> changes in v2:
>>> - explain with examples how the log's appearance changes, in patches 3-5
>>>   [Ingo]
>>>
>>> v1 blurb:
>>>
>>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>>> verify the memory types (an enum) and the memory attributes (a
>>>> bitmap). This series renders those columns human-readable, and unifies
>>>> their formatting between x86, ia64 and arm64.
>>>
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>>
>> The only thing I am not entirely convinced about is printing all those
>> memory attributes: is it really so interesting to know that region X
>> /can/ be configured as writeback, write through, write combining etc
>> etc, as most regions seem to support most attributes, yet it tells you
>> nothing about what the kernel ends up doing with that information. In
>> the arm64 case, for instance, all MEMORY_WB ranges are mapped
>> writeback cached, and everything else is mapped uncached.
>
> You don't need these attributes spelled out when you're not debugging.
> In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
> or don't pass uefi_debug=1 (on arm64).
>
> When you're debugging however, you need every bit of info you can get.
> For example, assume a tricky bug in exactly that part of the arm64 code
> that you just described above. You'll be flip-flopping between the
> kernel source and the original, pristine memory map dump. It's much
> easier to ignore a few words / columns in the log (even: cut it out with
> a script or interactively) than to read bitmaps in hex (or to decode
> them in a script). I know because I grew to hate these hex-encoded
> attributes and dec-encoded enum constants when I was developing S3 for
> OVMF, and fighting the memmap.
>
> A good analogue is ACPI debugging in the kernel. The ACPI subsystem
> comes with a very elaborate heap of switches, facility bitmaps, log
> levels, and so on. The end result is that it is faster to add printks to
> your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
> to use the acpi debug flags. (And I did the former when I was recently
> fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)
>
> So yes, I think that this detailed format is preferable.
>

OK, you've convinced me :-)

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Cheers,
Ard.

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Ard Biesheuvel]

On 3 September 2014 15:24, Laszlo Ersek <lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 09/03/14 15:01, Ard Biesheuvel wrote:
>> On 3 September 2014 13:32, Laszlo Ersek <lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> changes in v2:
>>> - explain with examples how the log's appearance changes, in patches 3-5
>>>   [Ingo]
>>>
>>> v1 blurb:
>>>
>>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>>> verify the memory types (an enum) and the memory attributes (a
>>>> bitmap). This series renders those columns human-readable, and unifies
>>>> their formatting between x86, ia64 and arm64.
>>>
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>>
>> The only thing I am not entirely convinced about is printing all those
>> memory attributes: is it really so interesting to know that region X
>> /can/ be configured as writeback, write through, write combining etc
>> etc, as most regions seem to support most attributes, yet it tells you
>> nothing about what the kernel ends up doing with that information. In
>> the arm64 case, for instance, all MEMORY_WB ranges are mapped
>> writeback cached, and everything else is mapped uncached.
>
> You don't need these attributes spelled out when you're not debugging.
> In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
> or don't pass uefi_debug=1 (on arm64).
>
> When you're debugging however, you need every bit of info you can get.
> For example, assume a tricky bug in exactly that part of the arm64 code
> that you just described above. You'll be flip-flopping between the
> kernel source and the original, pristine memory map dump. It's much
> easier to ignore a few words / columns in the log (even: cut it out with
> a script or interactively) than to read bitmaps in hex (or to decode
> them in a script). I know because I grew to hate these hex-encoded
> attributes and dec-encoded enum constants when I was developing S3 for
> OVMF, and fighting the memmap.
>
> A good analogue is ACPI debugging in the kernel. The ACPI subsystem
> comes with a very elaborate heap of switches, facility bitmaps, log
> levels, and so on. The end result is that it is faster to add printks to
> your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
> to use the acpi debug flags. (And I did the former when I was recently
> fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)
>
> So yes, I think that this detailed format is preferable.
>

OK, you've convinced me :-)

Acked-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Cheers,
Ard.

[PATCH v2 0/5] beautify EFI memmap logs

[Ard Biesheuvel]

On 3 September 2014 15:24, Laszlo Ersek <lersek@redhat.com> wrote:
> On 09/03/14 15:01, Ard Biesheuvel wrote:
>> On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
>>> changes in v2:
>>> - explain with examples how the log's appearance changes, in patches 3-5
>>>   [Ingo]
>>>
>>> v1 blurb:
>>>
>>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>>> verify the memory types (an enum) and the memory attributes (a
>>>> bitmap). This series renders those columns human-readable, and unifies
>>>> their formatting between x86, ia64 and arm64.
>>>
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>>
>> The only thing I am not entirely convinced about is printing all those
>> memory attributes: is it really so interesting to know that region X
>> /can/ be configured as writeback, write through, write combining etc
>> etc, as most regions seem to support most attributes, yet it tells you
>> nothing about what the kernel ends up doing with that information. In
>> the arm64 case, for instance, all MEMORY_WB ranges are mapped
>> writeback cached, and everything else is mapped uncached.
>
> You don't need these attributes spelled out when you're not debugging.
> In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
> or don't pass uefi_debug=1 (on arm64).
>
> When you're debugging however, you need every bit of info you can get.
> For example, assume a tricky bug in exactly that part of the arm64 code
> that you just described above. You'll be flip-flopping between the
> kernel source and the original, pristine memory map dump. It's much
> easier to ignore a few words / columns in the log (even: cut it out with
> a script or interactively) than to read bitmaps in hex (or to decode
> them in a script). I know because I grew to hate these hex-encoded
> attributes and dec-encoded enum constants when I was developing S3 for
> OVMF, and fighting the memmap.
>
> A good analogue is ACPI debugging in the kernel. The ACPI subsystem
> comes with a very elaborate heap of switches, facility bitmaps, log
> levels, and so on. The end result is that it is faster to add printks to
> your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
> to use the acpi debug flags. (And I did the former when I was recently
> fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)
>
> So yes, I think that this detailed format is preferable.
>

OK, you've convinced me :-)

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Cheers,
Ard.

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Ard Biesheuvel]

On 3 September 2014 15:24, Laszlo Ersek <lersek@redhat.com> wrote:
> On 09/03/14 15:01, Ard Biesheuvel wrote:
>> On 3 September 2014 13:32, Laszlo Ersek <lersek@redhat.com> wrote:
>>> changes in v2:
>>> - explain with examples how the log's appearance changes, in patches 3-5
>>>   [Ingo]
>>>
>>> v1 blurb:
>>>
>>>> It's a pain to analyze EFI memmap logs while debugging, especially to
>>>> verify the memory types (an enum) and the memory attributes (a
>>>> bitmap). This series renders those columns human-readable, and unifies
>>>> their formatting between x86, ia64 and arm64.
>>>
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> (on arm64 only)
>>
>> +1 for aligning between architectures
>> +1 for cleaning up the output to make it more readable
>>
>> The only thing I am not entirely convinced about is printing all those
>> memory attributes: is it really so interesting to know that region X
>> /can/ be configured as writeback, write through, write combining etc
>> etc, as most regions seem to support most attributes, yet it tells you
>> nothing about what the kernel ends up doing with that information. In
>> the arm64 case, for instance, all MEMORY_WB ranges are mapped
>> writeback cached, and everything else is mapped uncached.
>
> You don't need these attributes spelled out when you're not debugging.
> In that case, either build without CONFIG_EFI_DEBUG (on x86 and ia64),
> or don't pass uefi_debug=1 (on arm64).
>
> When you're debugging however, you need every bit of info you can get.
> For example, assume a tricky bug in exactly that part of the arm64 code
> that you just described above. You'll be flip-flopping between the
> kernel source and the original, pristine memory map dump. It's much
> easier to ignore a few words / columns in the log (even: cut it out with
> a script or interactively) than to read bitmaps in hex (or to decode
> them in a script). I know because I grew to hate these hex-encoded
> attributes and dec-encoded enum constants when I was developing S3 for
> OVMF, and fighting the memmap.
>
> A good analogue is ACPI debugging in the kernel. The ACPI subsystem
> comes with a very elaborate heap of switches, facility bitmaps, log
> levels, and so on. The end result is that it is faster to add printks to
> your suspect location(s) in ACPI, rebuild, retest, repeat, than to learn
> to use the acpi debug flags. (And I did the former when I was recently
> fixing a bug in the RHEL-6 kernel, in the intersection of ACPI and EFI.)
>
> So yes, I think that this detailed format is preferable.
>

OK, you've convinced me :-)

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Cheers,
Ard.

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Matt Fleming]

On Wed, 03 Sep, at 01:32:18PM, Laszlo Ersek wrote:
> changes in v2:
> - explain with examples how the log's appearance changes, in patches 3-5
>   [Ingo]
> 
> v1 blurb:
> 
> > It's a pain to analyze EFI memmap logs while debugging, especially to
> > verify the memory types (an enum) and the memory attributes (a
> > bitmap). This series renders those columns human-readable, and unifies
> > their formatting between x86, ia64 and arm64.
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (5):
>   efi: add macro for EFI_MEMORY_UCE memory attribute
>   efi: introduce efi_md_typeattr_format()
>   x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
>   ia64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>   arm64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
> 
>  include/linux/efi.h         |  8 +++++++
>  arch/arm64/kernel/efi.c     | 26 +++++----------------
>  arch/ia64/kernel/efi.c      |  6 +++--
>  arch/x86/platform/efi/efi.c |  7 ++++--
>  drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 80 insertions(+), 24 deletions(-)

Thanks Laszlo, applied to the 'next' branch with Ard's Tested-by and
Acked-by tags.

-- 
Matt Fleming, Intel Open Source Technology Center

[PATCH v2 0/5] beautify EFI memmap logs

[Matt Fleming]

On Wed, 03 Sep, at 01:32:18PM, Laszlo Ersek wrote:
> changes in v2:
> - explain with examples how the log's appearance changes, in patches 3-5
>   [Ingo]
> 
> v1 blurb:
> 
> > It's a pain to analyze EFI memmap logs while debugging, especially to
> > verify the memory types (an enum) and the memory attributes (a
> > bitmap). This series renders those columns human-readable, and unifies
> > their formatting between x86, ia64 and arm64.
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (5):
>   efi: add macro for EFI_MEMORY_UCE memory attribute
>   efi: introduce efi_md_typeattr_format()
>   x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
>   ia64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>   arm64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
> 
>  include/linux/efi.h         |  8 +++++++
>  arch/arm64/kernel/efi.c     | 26 +++++----------------
>  arch/ia64/kernel/efi.c      |  6 +++--
>  arch/x86/platform/efi/efi.c |  7 ++++--
>  drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 80 insertions(+), 24 deletions(-)

Thanks Laszlo, applied to the 'next' branch with Ard's Tested-by and
Acked-by tags.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [PATCH v2 0/5] beautify EFI memmap logs

[Matt Fleming]

On Wed, 03 Sep, at 01:32:18PM, Laszlo Ersek wrote:
> changes in v2:
> - explain with examples how the log's appearance changes, in patches 3-5
>   [Ingo]
> 
> v1 blurb:
> 
> > It's a pain to analyze EFI memmap logs while debugging, especially to
> > verify the memory types (an enum) and the memory attributes (a
> > bitmap). This series renders those columns human-readable, and unifies
> > their formatting between x86, ia64 and arm64.
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (5):
>   efi: add macro for EFI_MEMORY_UCE memory attribute
>   efi: introduce efi_md_typeattr_format()
>   x86: efi: format EFI memory type & attrs with efi_md_typeattr_format()
>   ia64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
>   arm64: efi: format EFI memory type & attrs with
>     efi_md_typeattr_format()
> 
>  include/linux/efi.h         |  8 +++++++
>  arch/arm64/kernel/efi.c     | 26 +++++----------------
>  arch/ia64/kernel/efi.c      |  6 +++--
>  arch/x86/platform/efi/efi.c |  7 ++++--
>  drivers/firmware/efi/efi.c  | 57 +++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 80 insertions(+), 24 deletions(-)

Thanks Laszlo, applied to the 'next' branch with Ard's Tested-by and
Acked-by tags.

-- 
Matt Fleming, Intel Open Source Technology Center