From: Boaz Harrosh <boaz@plexistor.com>
To: Dan Williams <dan.j.williams@intel.com>, linux-nvdimm@ml01.01.org
Cc: linux-kernel@vger.kernel.org,
Andy Lutomirski <luto@amacapital.net>, Jens Axboe <axboe@fb.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Christoph Hellwig <hch@lst.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH 01/21] e820, efi: add ACPI 6.0 persistent memory types
Date: Sun, 19 Apr 2015 10:46:38 +0300 [thread overview]
Message-ID: <55335D5E.40806@plexistor.com> (raw)
In-Reply-To: <20150418013519.25237.16129.stgit@dwillia2-desk3.amr.corp.intel.com>
On 04/18/2015 04:35 AM, Dan Williams wrote:
> ACPI 6.0 formalizes e820-type-7 and efi-type-14 as persistent memory.
> Mark it "reserved" and allow it to be claimed by a persistent memory
> device driver.
>
> This definition is in addition to the Linux kernel's existing type-12
> definition that was recently added in support of shipping platforms with
> NVDIMM support that predate ACPI 6.0 (which now classifies type-12 as
> OEM reserved). We may choose to exploit this wealth of definitions for
> NVDIMMs to differentiate E820_PRAM (type-12) from E820_PMEM (type-7).
> One potential differentiation is that PMEM is not backed by struct page
> by default in contrast to PRAM. For now, they are effectively treated
> as aliases by the mm.
>
> Note, /proc/iomem can be consulted for differentiating legacy
> "Persistent RAM" E820_PRAM vs standard "Persistent I/O Memory"
> E820_PMEM.
>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Boaz Harrosh <boaz@plexistor.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Jens Axboe <axboe@fb.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> ---
> arch/arm64/kernel/efi.c | 1 +
> arch/ia64/kernel/efi.c | 1 +
> arch/x86/boot/compressed/eboot.c | 4 ++++
> arch/x86/include/uapi/asm/e820.h | 1 +
> arch/x86/kernel/e820.c | 25 +++++++++++++++++++------
> arch/x86/platform/efi/efi.c | 3 +++
> include/linux/efi.h | 3 ++-
> 7 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index ab21e0d58278..9d4aa18f2a82 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -158,6 +158,7 @@ static __init int is_reserve_region(efi_memory_desc_t *md)
> case EFI_BOOT_SERVICES_CODE:
> case EFI_BOOT_SERVICES_DATA:
> case EFI_CONVENTIONAL_MEMORY:
> + case EFI_PERSISTENT_MEMORY:
> return 0;
> default:
> break;
> diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
> index c52d7540dc05..cd8b7485e396 100644
> --- a/arch/ia64/kernel/efi.c
> +++ b/arch/ia64/kernel/efi.c
> @@ -1227,6 +1227,7 @@ efi_initialize_iomem_resources(struct resource *code_resource,
> case EFI_RUNTIME_SERVICES_CODE:
> case EFI_RUNTIME_SERVICES_DATA:
> case EFI_ACPI_RECLAIM_MEMORY:
> + case EFI_PERSISTENT_MEMORY:
> default:
> name = "reserved";
> break;
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index ef17683484e9..dde5bf7726f4 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -1222,6 +1222,10 @@ static efi_status_t setup_e820(struct boot_params *params,
> e820_type = E820_NVS;
> break;
>
> + case EFI_PERSISTENT_MEMORY:
> + e820_type = E820_PMEM;
> + break;
> +
> default:
> continue;
> }
> diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
> index 960a8a9dc4ab..0f457e6eab18 100644
> --- a/arch/x86/include/uapi/asm/e820.h
> +++ b/arch/x86/include/uapi/asm/e820.h
> @@ -32,6 +32,7 @@
> #define E820_ACPI 3
> #define E820_NVS 4
> #define E820_UNUSABLE 5
> +#define E820_PMEM 7
>
> /*
> * This is a non-standardized way to represent ADR or NVDIMM regions that
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index 11cc7d54ec3f..410af501a941 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -137,6 +137,8 @@ static void __init e820_print_type(u32 type)
> case E820_RESERVED_KERN:
> printk(KERN_CONT "usable");
> break;
> + case E820_PMEM:
> + case E820_PRAM:
NACK!
This is the most important print in the system and it is a pure
user Interface. It has no effect what so ever on functionality
It is to Inform the user through dmesg what is the content of the
table.
> case E820_RESERVED:
> printk(KERN_CONT "reserved");
> break;
> @@ -149,9 +151,6 @@ static void __init e820_print_type(u32 type)
> case E820_UNUSABLE:
> printk(KERN_CONT "unusable");
> break;
+ case E820_PMEM:
> - case E820_PRAM:
> - printk(KERN_CONT "persistent (type %u)", type);
> - break;
Just add the new (7) entry here please. Here Christoph has bike shed
it for you.
> default:
> printk(KERN_CONT "type %u", type);
> break;
> @@ -919,10 +918,26 @@ static inline const char *e820_type_to_string(int e820_type)
> case E820_NVS: return "ACPI Non-volatile Storage";
> case E820_UNUSABLE: return "Unusable memory";
> case E820_PRAM: return "Persistent RAM";
> + case E820_PMEM: return "Persistent I/O Memory";
> default: return "reserved";
> }
> }
>
> +static bool do_mark_busy(u32 type, struct resource *res)
> +{
> + if (res->start < (1ULL<<20))
> + return true;
> +
> + switch (type) {
> + case E820_RESERVED:
> + case E820_PRAM:
> + case E820_PMEM:
> + return false;
> + default:
> + return true;
> + }
Sigh. Again an unknown type comes out busy. Busy means
resource used. It does *not* mean "unknown type".
It just forces researchers to ignore the return value of
request_region. And not be protected by double lock. It
does not really prevent anything
Thanks
Boaz
> +}
> +
> /*
> * Mark e820 reserved areas as busy for the resource manager.
> */
> @@ -952,9 +967,7 @@ void __init e820_reserve_resources(void)
> * pci device BAR resource and insert them later in
> * pcibios_resource_survey()
> */
> - if (((e820.map[i].type != E820_RESERVED) &&
> - (e820.map[i].type != E820_PRAM)) ||
> - res->start < (1ULL<<20)) {
> + if (do_mark_busy(e820.map[i].type, res)) {
> res->flags |= IORESOURCE_BUSY;
> insert_resource(&iomem_resource, res);
> }
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index dbc8627a5cdf..a116e236ac3f 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -145,6 +145,9 @@ static void __init do_add_efi_memmap(void)
> case EFI_UNUSABLE_MEMORY:
> e820_type = E820_UNUSABLE;
> break;
> + case EFI_PERSISTENT_MEMORY:
> + e820_type = E820_PMEM;
> + break;
> default:
> /*
> * EFI_RESERVED_TYPE EFI_RUNTIME_SERVICES_CODE
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index cf7e431cbc73..28868504aa17 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -85,7 +85,8 @@ typedef struct {
> #define EFI_MEMORY_MAPPED_IO 11
> #define EFI_MEMORY_MAPPED_IO_PORT_SPACE 12
> #define EFI_PAL_CODE 13
> -#define EFI_MAX_MEMORY_TYPE 14
> +#define EFI_PERSISTENT_MEMORY 14
> +#define EFI_MAX_MEMORY_TYPE 15
>
> /* Attribute values: */
> #define EFI_MEMORY_UC ((u64)0x0000000000000001ULL) /* uncached */
>
next prev parent reply other threads:[~2015-04-19 7:46 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-18 1:35 [PATCH 00/21] ND: NFIT-Defined / NVDIMM Subsystem Dan Williams
2015-04-18 1:35 ` [PATCH 01/21] e820, efi: add ACPI 6.0 persistent memory types Dan Williams
2015-04-18 4:41 ` Andy Lutomirski
2015-04-19 7:46 ` Boaz Harrosh [this message]
2015-04-20 17:08 ` Dan Williams
2015-04-28 12:46 ` [Linux-nvdimm] " Christoph Hellwig
2015-04-28 19:20 ` Dan Williams
2015-04-18 1:35 ` [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem Dan Williams
2015-04-20 7:06 ` Ingo Molnar
2015-04-20 8:14 ` Dan Williams
2015-04-20 12:53 ` Christoph Hellwig
2015-04-20 15:57 ` Dan Williams
2015-04-21 13:38 ` Dan Williams
2015-04-28 12:48 ` [Linux-nvdimm] " Christoph Hellwig
2015-04-18 1:35 ` [PATCH 03/21] nd_acpi: initial core implementation and nfit skeleton Dan Williams
2015-04-18 19:41 ` Paul Bolle
2015-04-19 19:12 ` Rafael J. Wysocki
2015-04-28 12:53 ` [Linux-nvdimm] " Christoph Hellwig
2015-04-28 19:21 ` Dan Williams
2015-04-18 1:35 ` [PATCH 04/21] nd: create an 'nd_bus' from an 'nfit_desc' Dan Williams
2015-04-21 19:35 ` [Linux-nvdimm] " Toshi Kani
2015-04-21 19:58 ` Dan Williams
2015-04-21 19:55 ` Toshi Kani
2015-04-21 20:35 ` Dan Williams
2015-04-21 20:32 ` Toshi Kani
2015-04-22 16:39 ` Toshi Kani
2015-04-22 17:03 ` Dan Williams
2015-04-22 18:00 ` Linda Knippers
2015-04-22 18:20 ` Dan Williams
2015-04-22 18:23 ` Toshi Kani
2015-04-22 19:28 ` Dan Williams
2015-04-22 19:38 ` Toshi Kani
2015-04-22 20:00 ` Dan Williams
2015-04-28 16:47 ` Toshi Kani
2015-04-28 17:14 ` Toshi Kani
2015-04-18 1:35 ` [PATCH 05/21] nfit-test: manufactured NFITs for interface development Dan Williams
2015-04-24 21:47 ` [Linux-nvdimm] " Linda Knippers
2015-04-24 21:50 ` Dan Williams
2015-04-24 21:59 ` Linda Knippers
2015-04-24 23:02 ` Dan Williams
2015-04-28 12:54 ` Christoph Hellwig
2015-04-28 19:35 ` Dan Williams
2015-04-18 1:35 ` [PATCH 06/21] nd: ndctl class device, and nd bus attributes Dan Williams
2015-04-18 8:07 ` Greg KH
2015-04-18 20:08 ` Dan Williams
2015-04-18 1:35 ` [PATCH 07/21] nd: dimm devices (nfit "memory-devices") Dan Williams
2015-04-18 8:06 ` Greg KH
2015-04-18 20:12 ` Dan Williams
2015-04-18 1:35 ` [PATCH 08/21] nd: ndctl.h, the nd ioctl abi Dan Williams
2015-04-21 21:20 ` [Linux-nvdimm] " Toshi Kani
2015-04-21 22:05 ` Dan Williams
2015-04-21 22:16 ` Toshi Kani
2015-04-24 15:56 ` Toshi Kani
2015-04-24 16:09 ` Toshi Kani
2015-04-24 16:31 ` Dan Williams
2015-04-24 16:25 ` Dan Williams
2015-04-24 17:18 ` Toshi Kani
2015-04-24 17:45 ` Dan Williams
2015-04-25 0:35 ` Toshi Kani
2015-04-18 1:36 ` [PATCH 09/21] nd_dimm: dimm driver and base nd-bus device-driver infrastructure Dan Williams
2015-04-18 1:36 ` [PATCH 10/21] nd: regions (block-data-window, persistent memory, volatile memory) Dan Williams
2015-04-18 1:36 ` [PATCH 11/21] nd_region: support for legacy nvdimms Dan Williams
2015-04-18 1:36 ` [PATCH 12/21] nd_pmem: add NFIT support to the pmem driver Dan Williams
2015-04-18 6:38 ` Christoph Hellwig
2015-04-18 19:37 ` Dan Williams
2015-04-28 12:56 ` [Linux-nvdimm] " Christoph Hellwig
2015-04-28 19:37 ` Dan Williams
2015-04-18 1:36 ` [PATCH 13/21] nd: add interleave-set state-tracking infrastructure Dan Williams
2015-04-18 1:36 ` [PATCH 14/21] nd: namespace indices: read and validate Dan Williams
2015-04-18 1:36 ` [PATCH 15/21] nd: pmem label sets and namespace instantiation Dan Williams
2015-04-18 1:36 ` [PATCH 16/21] nd: blk labels " Dan Williams
2015-04-18 1:36 ` [PATCH 17/21] nd: write pmem label set Dan Williams
2015-04-18 1:36 ` [PATCH 18/21] nd: write blk " Dan Williams
2015-04-18 1:36 ` [PATCH 19/21] nd: infrastructure for btt devices Dan Williams
2015-04-22 19:12 ` [Linux-nvdimm] " Elliott, Robert (Server Storage)
2015-04-22 19:39 ` Dan Williams
2015-04-28 13:01 ` Christoph Hellwig
2015-04-28 15:42 ` Matthew Wilcox
2015-04-18 1:37 ` [PATCH 20/21] nd_btt: atomic sector updates Dan Williams
2015-04-18 1:37 ` [PATCH 21/21] nd_blk: nfit blk driver Dan Williams
2015-04-18 19:29 ` [PATCH 00/21] ND: NFIT-Defined / NVDIMM Subsystem Dan Williams
2015-04-22 19:06 ` [Linux-nvdimm] " Elliott, Robert (Server Storage)
2015-04-22 19:39 ` Dan Williams
2015-04-23 5:43 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55335D5E.40806@plexistor.com \
--to=boaz@plexistor.com \
--cc=axboe@fb.com \
--cc=dan.j.williams@intel.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=ross.zwisler@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox