Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <122aefbf-0ed7-cdd3-5c0a-3d1c51429598@redhat.com>
Date:   Thu, 31 Aug 2023 16:18:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [RFC PATCH] Introduce persistent memory pool
Content-Language: en-US
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc:     Stanislav Kinsburskii <stanislav.kinsburskii@gmail.com>,
        Derek Kiernan <derek.kiernan@amd.com>,
        Dragan Cvetic <dragan.cvetic@amd.com>,
        Arnd Bergmann <arnd@arndb.de>, Wei Liu <wei.liu@kernel.org>,
        "K. Y. Srinivasan" <kys@microsoft.com>,
        Madhavan Venkataraman <madvenka@linux.microsoft.com>,
        Anthony Yznaga <anthony.yznaga@oracle.com>,
        "Mike Rapoport (IBM)" <rppt@kernel.org>,
        James Gowans <jgowans@amazon.com>,
        Anirudh Rayabharam <anrayabh@linux.microsoft.com>,
        Jinank Jain <jinankjain@linux.microsoft.com>,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
References: <64e7cbf7.050a0220.114c7.b70dSMTPIN_ADDED_BROKEN@mx.google.com>
 <2023082506-enchanted-tripping-d1d5@gregkh>
 <64e8f6dd.050a0220.edb3c.c045SMTPIN_ADDED_BROKEN@mx.google.com>
 <2023082633-magnetize-cupcake-accc@gregkh>
 <64ea25cd.650a0220.642cc.50e6SMTPIN_ADDED_BROKEN@mx.google.com>
 <2023082620-saint-petition-bb89@gregkh>
 <64ea3699.170a0220.13ee0.5c3aSMTPIN_ADDED_BROKEN@mx.google.com>
 <2023082619-puzzling-viewable-fa69@gregkh>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <2023082619-puzzling-viewable-fa69@gregkh>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

Paolo