Re: [RFC PATCH] Introduce persistent memory pool

[Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>]

On Thu, Aug 31, 2023 at 04:18:48PM +0200, Paolo Bonzini wrote:
> On 8/26/23 22:04, Greg Kroah-Hartman wrote:
> > > Yeah, I guess the "ABI" word in misleading here, especially the first
> > > letter. I mean something else: the old kernel/new kernel.
> > > This persistent memory pool (its metadata) is supposed to be passed
> > > across kexec with the data. That is probably the main difference in
> > > comparison to pmem or cma.
> > > Since the header can change its format between kernels, there should be
> > > a way to identify it.
> > 
> > Ah.  Hah, that's crazy, and it's never going to work, you need to just
> > test the version of the kernel that the image was created for (you have
> > that in the kernel already) and verify that it is the same before
> > loading the new one.
> > 
> > That way you never have to worry about any "version number", it's just
> > the kernel specific version number instead.
> 
> Checking the version of the kernel is not enough because you want to support
> kexec to a newer kernel.
> 
> I agree though that a version number is not needed.  In the end this is just
> like a filesystem and you'd better keep it backwards compatible. If you
> think you might need an extra field in the header, you have to leave some
> padding and add a "flags" field that right now is always zero.  Or something
> like that.
> 

Thanks for laying it out. I was also thinking about some pads to reserve
in metadata upfront to allow future extensions.
But I guess if we decide to store metadata in device tree, then this
padding won't be required.

Thanks,
Stanislav

> Paolo