Re: [RFC PATCH 2/2] mm/pmem: Add memblock based e820 platform driver

["Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>]

On 07/07/2018 11:06 PM, Dan Williams wrote:
> On Sat, Jul 7, 2018 at 12:15 AM, Oliver <oohall@gmail.com> wrote:
>> On Sat, Jul 7, 2018 at 5:38 AM, Dan Williams <dan.j.williams@intel.com> wrote:
>>> On Fri, Jul 6, 2018 at 1:29 AM, Aneesh Kumar K.V
>>> <aneesh.kumar@linux.ibm.com> wrote:
>>>> This patch steal system RAM and use that to emulate pmem device using the
>>>> e820 platform driver.
>>>>
>>>> This adds a new kernel command line 'pmemmap' which takes the format <size[KMG]>
>>>> to allocate memory early in the boot. This memory is later registered as
>>>> persistent memory range.
>>>>
>>>> Based on original patch from Oliver OHalloran <oliveroh@au1.ibm.com>
>>>>
>>>> Not-Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>>> ---
>>>>   drivers/nvdimm/Kconfig        |  13 ++++
>>>>   drivers/nvdimm/Makefile       |   1 +
>>>>   drivers/nvdimm/memblockpmem.c | 115 ++++++++++++++++++++++++++++++++++
>>>>   3 files changed, 129 insertions(+)
>>>>   create mode 100644 drivers/nvdimm/memblockpmem.c
>>>>
>>> [..]
>>>> +/*
>>>> + * pmemmap=ss[KMG]
>>>> + *
>>>> + * This is similar to the memremap=offset[KMG]!size[KMG] paramater
>>>> + * for adding a legacy pmem range to the e820 map on x86, but it's
>>>> + * platform agnostic.
>>
>>> The current memmap=ss!nn option is a non-stop source of bugs and
>>> fragility. The fact that this lets the kernel specify the base address
>>> helps, but then this is purely just a debug facility because
>>> memmap=ss!nn is there to cover platform firmware implementations that
>>> fail to mark a given address range as persistent.
>>
>>> If this is just for debug, why not use qemu?
>>
>> To make a long story short, we have two virtualisation stacks and only one of
>> them is based on qemu. An unfortunately large chunk of our customers (and
>> our internal test systems) run the other one so we need to accommodate them
>> somehow.
>>
>>> If this is not for debug what are these systems that don't have proper firmware
>>> support?
>>
>> I wrote the original version (for RHEL 7.something) for a customer who wanted
>> to do some testing which needed to be run on real hardware for some reason.
>> We couldn't install a FW update on their system so this ended up being the least
>> painful way to get them going. That's not a strong argument for
>> merging this, but
>> the point is that it's sometimes useful to have the capability in the kernel.
> 
> Ok, correct me if I'm wrong, but it seems to be purely about debug and
> emulation? If that's the case would it be acceptable to just add more
> capabilities to tools/testing/nvdimm/ for what you want to do? That
> has been our primary vehicle for testing libnvdimm.
> 

What we need is the ability to run with fsdax on hypervisor other than KVM.

-aneesh