From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6BBAC021A0 for ; Wed, 12 Feb 2025 16:39:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 385E56B0082; Wed, 12 Feb 2025 11:39:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 334F26B0083; Wed, 12 Feb 2025 11:39:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FD276B0085; Wed, 12 Feb 2025 11:39:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0198A6B0082 for ; Wed, 12 Feb 2025 11:39:28 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A86F8122340 for ; Wed, 12 Feb 2025 16:39:28 +0000 (UTC) X-FDA: 83111853216.20.ED4F72D Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf21.hostedemail.com (Postfix) with ESMTP id DE7A11C0011 for ; Wed, 12 Feb 2025 16:39:26 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LwS+nkzE; spf=pass (imf21.hostedemail.com: domain of rppt@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739378366; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=o9EcgwaoNH9P8S3TSPAC5aJNBCxAKdO1YHsWC1zruTc=; b=70NtJO0JHVrrY360EDt7TeVnbE7lgDEdWOObs75x/6TElh8vjHHq00gaTIA1/nk7Ux6Ljz vH5JzuYtt0dGaasJ2Mgd2dgMargyerVsqtwN8N9MZwAq3ZThpl4TPFGe/mtTtPTzwMhiN8 crbpTswONEpeHRbhCzF6/oWg/qgwEXk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LwS+nkzE; spf=pass (imf21.hostedemail.com: domain of rppt@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739378366; a=rsa-sha256; cv=none; b=tY3imRTViwaWUGE8N3lw1mFZQJlyR4Yc39XDk81RpTpuhQPu7Yd+Hh+xL7kVRGrxFsY3M0 iKZCEYRLzVxtF6c3McLQcXxI1Imt6zSCwW3v9j+HwsC3Wv2ie04K00Mqbxtxo6ijbN0Agr cfgya5jV3AUGNEJxzZF9LJLt+quIjC4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id B22D2A40C19; Wed, 12 Feb 2025 16:37:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B45E0C4CEDF; Wed, 12 Feb 2025 16:39:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739378365; bh=zfEIpiTrcj/R2Ru79c+QdETWalY9N06YUbZ/uIkxoRU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LwS+nkzE62iYAWY6oMvTiOE2hZdqZW4je7lUt/Tn8svDT0aqJyRSG1Te50dWeoSK6 yZO90wTxRzWvs64nxtq+JimjJqslPOcN7j/gDEv42ILOhCNdmCR6wWLQcePUqYZ0Yz uadqjYhtm/BeUJnOKtwxaC2USAWhcuMi9AeP4KLnjL50JLMhS7jyRHMJsejxavbVDh sV1QU2dtmz9BzlPJHJQTzkrOQXYWw8C3AzJ/mP1FzbO60nnOuds/LnOuA/bs/jEEl1 +GgoenuPWq9nhK1ojBt2vq5J0TI5Wg9+EvPg0Lk5i7f20zfeNS5Qm+VHUuZdt6qoTp WjzuuOLLR6qTQ== Date: Wed, 12 Feb 2025 18:39:06 +0200 From: Mike Rapoport To: Jason Gunthorpe Cc: Pasha Tatashin , linux-kernel@vger.kernel.org, Alexander Graf , Andrew Morton , Andy Lutomirski , Anthony Yznaga , Arnd Bergmann , Ashish Kalra , Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Dave Hansen , David Woodhouse , Eric Biederman , Ingo Molnar , James Gowans , Jonathan Corbet , Krzysztof Kozlowski , Mark Rutland , Paolo Bonzini , "H. Peter Anvin" , Peter Zijlstra , Pratyush Yadav , Rob Herring , Rob Herring , Saravana Kannan , Stanislav Kinsburskii , Steven Rostedt , Thomas Gleixner , Tom Lendacky , Usama Arif , Will Deacon , devicetree@vger.kernel.org, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org Subject: Re: [PATCH v4 05/14] kexec: Add Kexec HandOver (KHO) generation helpers Message-ID: References: <20250206132754.2596694-1-rppt@kernel.org> <20250206132754.2596694-6-rppt@kernel.org> <20250210202220.GC3765641@nvidia.com> <20250211124943.GC3754072@nvidia.com> <20250211163720.GH3754072@nvidia.com> <20250212152336.GA3848889@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250212152336.GA3848889@nvidia.com> X-Rspam-User: X-Rspamd-Queue-Id: DE7A11C0011 X-Stat-Signature: acpdca1j6j73awtb8jswrqzaj8b5mbih X-Rspamd-Server: rspam03 X-HE-Tag: 1739378366-231054 X-HE-Meta: U2FsdGVkX18uYlbDvXndU1QXNxBiAyAGCZZfJgVrDm0Hi09zTFOCV11Zup/ZYt/jszLYurHJmr60sfNL+FJQOmAiMb0YOSUfGBKr/+AP+84s10owUAclwH3GcQLGpRXvuuMn5gEqP9xGuleWPX+0Di71tbaV8HxpMbNqQhJd2PnJeWxfTl5VosjtZ9VpBK1nKMvypZJKXySIPO8T15IwPiuoEKBxqEKJCsyMJxb0KrxvUlNRXeGM/EVGlfOTyudKkDqsRWpzTayZoKO3UwVS0GcfjlxhLzQA4gagHeirwddpXBDoJixRTrmRAA7yMmNxsNvuCzFxGXcKThVZ6uxUeWFZbLezyXaIzDVYn4mvBSIFcIFEWlTGYV1uod3HtDuvUOad9ftaBZXjR4Pm1Bj9pA02ILT5tCVbkhvV5qRdZU5611QTfZ7Bg1zZpuqK4+imDqu5VLBsCG74V69nIehSjXzaSpHpW51hB71Ky/TVtK14hl5IzdBG60rL1ZOk1CyUNivEHOW5I9lS9EhvQASjndeJEcNlfcCSRqjQs/MXtYPaIEQTHBpyuVY8t4Z1PSeJLGmu84CssBqVCXYrPzw0cTwzK6GUPaShiBfqUacGT2HreS4hA9aeQ1TAGOal7Y1WRKjx8mzaYqp5wcbSdtKMJgo/1zAUzANNGs67O3KrIdRQQQq0BXAwfcpu+pOrM2asYVlsv0yTUtCR9vmu/35sTeK83uz0+Ujfd7G3TQshBoJKE9iMX6dDTOiPNqz6JWg/sJn6OLulJJ2gYrWf7vPArRlFmUDADVn6BCWtulZfSuOzRyg1TUBAIbTt4gyBDhnkVXwfFC8VLOUz074mQ4bwExaWtYbySmykvF5g4kY8CFJzHYBpw3ra93z3ToHUQtH/RpDEc+yNz0lOF3vhpMB5afYc5z5iPoQrh433XA4/GnQT5pc5ExnvUpsLxT6bDuQ/TWHMVeojPhW0T9rktzJ 9162uDq5 Ct+DC6Ol93j3IPE2ZKUhurYcZO3iBBbHezjHZk3o3GBnRUVji0I1wPcu8rzBMn6qUDq/43KO23qe/wZdMeU7KupDfEq6vE7hSJiRZ6fHW6S0WRtfBc8mu6LnptEKC2m1sunhHRsJurzQXPzhtcpks99NQ9m5at1NYPkm358pV6HlNRt1UGzrFI+NNuTSaaPQfvmlQRcyxUwCqtEDXjGvqypqeSEp02W9h1AzYAa8zhBV9NvuabZT6POps8eRGyDRdJLo0uiZrL454OLiDULkL9dO09/5+eDBCMB879na2jNXxOS+jMSz+l9qeaVtCg/rBGO4u8DMHpnKr/Ng= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Jason, On Wed, Feb 12, 2025 at 11:23:36AM -0400, Jason Gunthorpe wrote: > On Tue, Feb 11, 2025 at 12:37:20PM -0400, Jason Gunthorpe wrote: > > > To do that you need to preserve folios as the basic primitive. > > I made a small sketch of what I suggest. > > I imagine the FDT schema for this would look something like this: > > /dts-v1/; > / { > compatible = "linux-kho,v1"; > phys-addr-size = 64; > void-p-size = 64; > preserved-folio-map = ; > > // The per "driver" storage > instance@1 {..}; > instance@2 {..}; > }; > > I think this is alot better than what is in this series. It uses much > less memory when there are alot of allocation, it supports any order > folios, it is efficient for 1G guestmemfd folios, and it only needs a > few bytes in the FDT. It could preserve and restore the high order > folio struct page folding (HVO). > > The use cases I'm imagining for drivers would be pushing gigabytes of > memory into this preservation mechanism. It needs to be scalable! > > This also illustrates my point that I don't think FDT is a good > representation to use exclusively. This in-memory structure is much > better and faster than trying to represent the same information > embedded directly into the FDT. I imagine this to be the general > pattern that drivers will want to use. A few bytes in the FDT pointing > at a scalable in-memory structure for the bulk of the data. 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. It's sole purpose is to allow preserving simple properties and ensure that memory ranges KHO clients need to preserve won't be overwritten. What you propose is a great optimization for memory preservation mechanism, and additional and very useful abstraction layer on top of "basic KHO"! 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. -- Sincerely yours, Mike.