All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Elliott, Robert (Server Storage)" <Elliott@hp.com>
To: Christoph Hellwig <hch@lst.de>,
	"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Cc: "ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"boaz@plexistor.com" <boaz@plexistor.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>
Subject: RE: [PATCH 3/3] x86: add support for the non-standard protected e820 type
Date: Wed, 25 Mar 2015 19:47:26 +0000	[thread overview]
Message-ID: <94D0CD8314A33A4D9D801C0FE68B40295A8429FC@G9W0745.americas.hpqcorp.net> (raw)
In-Reply-To: <1427299449-26722-4-git-send-email-hch@lst.de>

A few editorial nits follow...

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Wednesday, March 25, 2015 11:04 AM
> Subject: [PATCH 3/3] x86: add support for the non-standard protected e820
> type
> 
> Various recent bioses support NVDIMMs or ADR using a non-standard
> e820 memory type, and Intel supplied reference Linux code using this
> type to various vendors.

If this goes into the kernel, I think someone should request that the
ACPI specification mark the value 12 as permanently tainted.  Otherwise
they could assign it to some new meaning that conflicts with all
of this.

A few editorial nits follow...

> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-
> parameters.txt
> index bfcb1a6..98eeaca 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1965,6 +1965,12 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
>  			         or
>  			         memmap=0x10000$0x18690000
> 
> +	memmap=nn[KMG]!ss[KMG]
> +			[KNL,X86] Mark specific memory as protected.
> +			Region of memory to be used, from ss to ss+nn.
> +			The memory region may be marked as type 12 and
> +			is NVDIMM or ADR memory.

It can be confusing that E820h type values differ from UEFI 
memory map type values, so it might be worth emphasizing that is 
an E820h type value.

Showing hex alongside would also clarify that it is indeed a 
decimal 12.

Suggestion: "e820 type 12 (0xc)"

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index b7d31ca..93a27e4 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1430,6 +1430,19 @@ config ILLEGAL_POINTER_VALUE
> 
>  source "mm/Kconfig"
> 
> +config X86_PMEM_LEGACY
> +	bool "Support non-stanard NVDIMMs and ADR protected memory"

stanard s/b standard


> +	help
> +	  Treat memory marked using the non-stard e820 type of 12 as used

stard s/b standard

> +	  by the Intel Sandy Bridge-EP reference BIOS as protected memory.
> +	  The kernel will the offer these regions to the pmem driver so

the s/b then

> +	  they can be used for persistent storage.
> +
> +	  If you say N the kernel will treat the ADR region like an e820
> +	  reserved region.
> +
> +	  Say Y if unsure
> +

...
> diff --git a/arch/x86/include/uapi/asm/e820.h
> b/arch/x86/include/uapi/asm/e820.h
> index d993e33..e040950 100644
> --- a/arch/x86/include/uapi/asm/e820.h
> +++ b/arch/x86/include/uapi/asm/e820.h
> @@ -33,6 +33,16 @@
>  #define E820_NVS	4
>  #define E820_UNUSABLE	5
> 
> +/*
> + * This is a non-standardized way to represent ADR or NVDIMM regions that
> + * persist over a reboot.  The kernel will ignore their special
> capabilities
> + * unless the CONFIG_X86_PMEM_LEGACY option is set.
> + *
> + * Note that older platforms also used 6 for the same type of memory,
> + * but newer versions switched to 12 as 6 was assigned differently.  Some
> + * time they will learn..
> + */
> +#define E820_PROTECTED_KERN	12

The p in pmem means persistent, not protected.  To me, protected sounds 
like a security feature.  I suggest using a different macro name and 
text strings.

...
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index de088e3..8c6a976 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -48,10 +48,22 @@ unsigned long pci_mem_start = 0xaeedbabe;
>  EXPORT_SYMBOL(pci_mem_start);
>  #endif
> 
> +/*
> + * Memory protected by the system ADR (asynchronous dram refresh)
> + * mechanism is accounted as ram for purposes of establishing max_pfn
> + * and mem_map.
> + */

ADR doesn't really protect or ensure persistence; it just puts memory 
into self-refresh mode. Batteries/capacitors and other logic is what
provides the persistence.

...
> @@ -154,6 +166,9 @@ static void __init e820_print_type(u32 type)
>  	case E820_UNUSABLE:
>  		printk(KERN_CONT "unusable");
>  		break;
> +	case E820_PROTECTED_KERN:
> +		printk(KERN_CONT "protected (type %u)\n", type);
> +		break;

Same "protect" comment applies there, and a few other places in
the patch not excerpted.



  reply	other threads:[~2015-03-25 19:48 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 16:04 another pmem variant Christoph Hellwig
2015-03-25 16:04 ` [PATCH 1/3] pmem: Initial version of persistent memory driver Christoph Hellwig
2015-03-25 20:19   ` Paul Bolle
2015-03-25 20:26     ` Ross Zwisler
2015-03-26  8:04       ` Christoph Hellwig
2015-03-25 20:21   ` Ross Zwisler
2015-03-26  8:06     ` Christoph Hellwig
2015-05-04 16:43       ` Ross Zwisler
2015-05-04 16:43         ` Ross Zwisler
2015-05-07  7:26         ` Christoph Hellwig
2015-05-07  8:35           ` Boaz Harrosh
2015-03-25 16:04 ` [PATCH 2/3] x86: add a is_e820_ram() helper Christoph Hellwig
2015-03-26  2:15   ` [Linux-nvdimm] " Dan Williams
2015-03-26  8:01     ` Christoph Hellwig
2015-03-26 13:57       ` Dan Williams
2015-03-26 14:32         ` Christoph Hellwig
2015-03-25 16:04 ` [PATCH 3/3] x86: add support for the non-standard protected e820 type Christoph Hellwig
2015-03-25 19:47   ` Elliott, Robert (Server Storage) [this message]
2015-03-26  8:02     ` Christoph Hellwig
2015-03-25 20:23   ` Ross Zwisler
2015-03-25 20:29     ` [Linux-nvdimm] " Dan Williams
2015-03-25 20:25   ` Ross Zwisler
2015-03-26  8:03     ` Christoph Hellwig
2015-03-25 20:35   ` [Linux-nvdimm] " Dan Williams
2015-03-25 16:33 ` [Linux-nvdimm] another pmem variant Dan Williams
2015-03-25 16:44   ` Christoph Hellwig
2015-03-25 17:00     ` Dan Williams
2015-03-25 17:04       ` Christoph Hellwig
2015-03-25 17:18         ` Dan Williams
2015-04-13  9:01       ` Greg KH
2015-04-13 16:02         ` Dan Williams
2015-03-25 18:09 ` Brooks, Adam J
2015-03-25 18:09   ` Brooks, Adam J
2015-03-25 18:46   ` Christoph Hellwig
2015-03-25 21:02 ` Ross Zwisler
2015-03-26  8:32 another pmem variant V2 Christoph Hellwig
2015-03-26  8:32 ` [PATCH 3/3] x86: add support for the non-standard protected e820 type Christoph Hellwig

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=94D0CD8314A33A4D9D801C0FE68B40295A8429FC@G9W0745.americas.hpqcorp.net \
    --to=elliott@hp.com \
    --cc=axboe@kernel.dk \
    --cc=boaz@plexistor.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=ross.zwisler@linux.intel.com \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.