linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Toshi Kani <toshi.kani@hpe.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] libnvdimm, pmem: adjust for section collisions with 'System RAM'
Date: Mon, 07 Mar 2016 11:58:41 -0700	[thread overview]
Message-ID: <1457377121.15454.366.camel@hpe.com> (raw)
In-Reply-To: <CAPcyv4i2vtdz8BGGBWR2eGXhW8nuA9w+gvGJN5P__Ks_PyyRRg@mail.gmail.com>

On Mon, 2016-03-07 at 09:18 -0800, Dan Williams wrote:
> On Mon, Mar 7, 2016 at 9:56 AM, Toshi Kani <toshi.kani@hpe.com> wrote:
> > On Fri, 2016-03-04 at 18:23 -0800, Dan Williams wrote:
> > > On Fri, Mar 4, 2016 at 6:48 PM, Toshi Kani <toshi.kani@hpe.com>
> > > wrote:
> [..]
> > > As far as I can see
> > > all we do is ask firmware implementations to respect Linux section
> > > boundaries and otherwise not change alignments.
> > 
> > In addition to the requirement that pmem range alignment may not
> > change, the code also requires a regular memory range does not change
> > to intersect with a pmem section later.A A This seems fragile to me since
> > guest config may vary / change as I mentioned above.
> > 
> > So, shouldn't the driver fails to attach when the range is not aligned
> > by the section size?A A Since we need to place a requirement to firmware
> > anyway, we can simply state that it must be aligned by 128MiB (at
> > least) on x86. A Then, memory and pmem physical layouts can be changed
> > as long as this requirement is met.
> 
> We can state that it must be aligned, but without a hard specification
> I don't see how we can guarantee it.A A We will fail the driver load
> with a warning if our alignment fixups end up getting invalidated by a
> later configuration change, but in the meantime we cover the gap of a
> BIOS that has generated a problematic configuration.

I do not think it has to be stated in the spec (although it may be a good
idea to state it as an implementation note :-).

This is an OS-unique requirement (and the size is x86-specific) that if it
wants to support Linux pmem pfn, then the alignment needs to be at least
128MiB. A Regular pmem does not have this restriction, but it needs to be
aligned by 2MiB or 1GiB for using huge page mapping, which does not have to
be stated in the spec, either.

For KVM to support the pmem pfn feature on x86, it needs to guarantee this
128MiB alignment. A Otherwise, this feature is not supported. A (I do not
worry about NVDIMM-N since it is naturally aligned by its size.)

If we allow unaligned cases, then the driver needs to detect change from
the initial condition and fail to attach for protecting data. A I did not
see such check in the code, but I may have overlooked. A We cannot check if
KVM has any guarantee to keep the alignment at the initial setup, though.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-03-07 18:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-03 21:53 [PATCH v2 0/3] libnvdimm, pfn: support section misaligned pmem Dan Williams
2016-03-03 21:53 ` [PATCH v2 1/3] libnvdimm, pmem: fix 'pfn' support for section-misaligned namespaces Dan Williams
2016-03-03 21:53 ` [PATCH v2 2/3] libnvdimm, pmem: adjust for section collisions with 'System RAM' Dan Williams
2016-03-05  2:48   ` Toshi Kani
2016-03-05  2:23     ` Dan Williams
2016-03-07 17:56       ` Toshi Kani
2016-03-07 17:18         ` Dan Williams
2016-03-07 18:58           ` Toshi Kani [this message]
2016-03-07 18:19             ` Dan Williams
2016-03-07 18:37             ` Dan Williams
2016-03-03 21:53 ` [PATCH v2 3/3] libnvdimm, pfn: 'resource'-address and 'size' attributes for pfn devices Dan Williams

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=1457377121.15454.366.camel@hpe.com \
    --to=toshi.kani@hpe.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox