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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 9 Jul 2018 10:47:28 +0530
From:   "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
To:     Dan Williams <dan.j.williams@...el.com>, Oliver <oohall@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 2/2] mm/pmem: Add memblock based e820 platform driver

On 07/07/2018 11:06 PM, Dan Williams wrote:
> On Sat, Jul 7, 2018 at 12:15 AM, Oliver <oohall@...il.com> wrote:
>> On Sat, Jul 7, 2018 at 5:38 AM, Dan Williams <dan.j.williams@...el.com> wrote:
>>> On Fri, Jul 6, 2018 at 1:29 AM, Aneesh Kumar K.V
>>> <aneesh.kumar@...ux.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@....ibm.com>
>>>>
>>>> Not-Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@...ux.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