[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250212174303.GU3754072@nvidia.com>
Date: Wed, 12 Feb 2025 13:43:03 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: Pasha Tatashin <pasha.tatashin@...een.com>,
linux-kernel@...r.kernel.org, Alexander Graf <graf@...zon.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>,
Anthony Yznaga <anthony.yznaga@...cle.com>,
Arnd Bergmann <arnd@...db.de>, Ashish Kalra <ashish.kalra@....com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Borislav Petkov <bp@...en8.de>,
Catalin Marinas <catalin.marinas@....com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Woodhouse <dwmw2@...radead.org>,
Eric Biederman <ebiederm@...ssion.com>,
Ingo Molnar <mingo@...hat.com>, James Gowans <jgowans@...zon.com>,
Jonathan Corbet <corbet@....net>,
Krzysztof Kozlowski <krzk@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Pratyush Yadav <ptyadav@...zon.de>,
Rob Herring <robh+dt@...nel.org>, Rob Herring <robh@...nel.org>,
Saravana Kannan <saravanak@...gle.com>,
Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Tom Lendacky <thomas.lendacky@....com>,
Usama Arif <usama.arif@...edance.com>,
Will Deacon <will@...nel.org>, devicetree@...r.kernel.org,
kexec@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
linux-doc@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org
Subject: Re: [PATCH v4 05/14] kexec: Add Kexec HandOver (KHO) generation
helpers
On Wed, Feb 12, 2025 at 06:39:06PM +0200, Mike Rapoport wrote:
> As I've mentioned off-list earlier, KHO in its current form is the lowest
> level of abstraction for state preservation and it is by no means is
> intended to provide complex drivers with all the tools necessary.
My point, is I think it is the wrong level of abstraction and the
wrong FDT schema. It does not and cannot solve the problems we know we
will have, so why invest anything into that schema?
I think the scratch system is great, and an amazing improvement over
past version. Upgrade the memory preservation to match and it will be
really good.
> What you propose is a great optimization for memory preservation mechanism,
> and additional and very useful abstraction layer on top of "basic KHO"!
I do not see this as a layer on top, I see it as fundamentally
replacing the memory preservation mechanism with something more
scalable.
> But I think it will be easier to start with something *very simple* and
> probably suboptimal and then extend it rather than to try to build complex
> comprehensive solution from day one.
But why? Just do it right from the start? I spent like a hour
sketching that, the existing preservation code is also very simple,
why not just fix it right now?
Jason
Powered by blists - more mailing lists