Messages in this thread | | | Subject | Re: [RFC PATCH 2/2] mm/pmem: Add memblock based e820 platform driver | From | "Aneesh Kumar K.V" <> | Date | Mon, 9 Jul 2018 10:47:28 +0530 |
| |
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
| |