[RFC][nvdimm][crash] pmem memmap dump support

[Dan Williams]

lizhijian at fujitsu.com wrote:
> 
> 
> On 17/03/2023 14:12, Dan Williams wrote:
> > lizhijian at fujitsu.com wrote:
> > [..]
> >> Case D: unsupported && need your input To support this situation, the
> >> makedumpfile needs to know the location of metadata for each pmem
> >> namespace and the address and size of metadata in the pmem [start,
> >> end)
> > 
> > My first reaction is that you should copy what the ndctl utility does
> > when it needs to manipulate or interrogate the metadata space.
> > 
> > For example, see namespace_rw_infoblock():> 
> > https://github.com/pmem/ndctl/blob/main/ndctl/namespace.c#L2022
> > 
> > That facility uses the force_raw attribute
> > ("/sys/bus/nd/devices/namespaceX.Y/force_raw") to arrange for the
> > namespace to initalize without considering any pre-existing metdata
> > *and* without overwriting it. In that mode makedumpfile can walk the
> > namespaces and retrieve the metadata written by the previous kernel.
> 
> For the dumping application(makedumpfile or cp), it will/should reads
> /proc/vmcore to construct the dumpfile, So makedumpfile need to know
> the *address* and *size/end* of metadata in the view of 1st kernel
> address space.

Another option, instead of passing the metadata layout into the crash
kernel, is to just parse the infoblock and calculate teh boundaries of
userdata and metadata.

> I haven't known much about namespace_rw_infoblock() , so it is also an
> option if we can know such information from it.
> 
> My current WIP propose is to export a list linking all pmem namespaces
> to vmcore, with this, the kdump kernel don't need to rely on the pmem
> driver.

Seems like more work to avoid using the pmem driver as new information
passing infrastructure needs to be built vs reusing what is already
there.