On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig <hch(a)lst.de> wrote:
On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote:
> This is mostly ok and does not collide too much with the upcoming ACPI
> mechanism for this stuff. I do worry that the new
> "memmap=nn[KMG]!ss[KMG]" kernel command line option will only be
> relevant for at most one kernel cycle given the imminent publication
> of the spec that unblocks our release.
I don't think we can just get rid of it as legacy systems won't be
upgraded to the new discovery mechanism. Or do you mean you plan to
introduce a better override on the command line? In that case speak
The kernel command line would simply be the standard/existing memmap=
to reserve a memory range. Then, when the platform device loads, it
does a request_firmware() to inject a binary table that further carves
memory into ranges to which the pmem driver attaches. No need for the
legacy system BIOS to be upgraded to the "new way".
> Our planned solution to the "legacy pmem" problem is to
> userspace utility craft a list of address ranges in the form that ACPI
> expects and attach that to a platform device (one time setup). It
> only requires that the memory be marked reserved, not necessarily
> marked type-12.
I can't see any benefit of that over just doign the right thing in
It does do the right thing in kernel space. The userspace utility
creates the binary table (once) that can be compiled into the platform
device driver or auto-loaded by an initrd. The problem with a new
memmap= is that it is too coarse. For example you can't do things
like specify a pmem range per-NUMA node.