From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3934A2882C9 for ; Tue, 13 Jan 2026 14:46:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768315569; cv=none; b=UIfV8X98/7Fcr71CffU6hifYzoFTvvgs4lx9gIIU4PznE2z4+6cwi7PvRNarySXYY2RAjhW4EdGzgVtg+AMAXlB6tTFUxiIrej5i5a2YklZxYDbPKRnbJ2Kd9NcOv6wt+rMCrE/7RYp7FQ/8EyVbESmmk1IrYHWw/MU7KcnMDgE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768315569; c=relaxed/simple; bh=4uCAucSurgWYYIfTPVGMA7hAEuKLq8ADMBBO1vAY/Ts=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k0LiaNAAIkwCO1C+OFx/7j3sO+lwoW9RiyrufLJT+kN3yxNGHRG+HejUVcWJbTxSnPBUyp5T6Mnl2WLdVPjL13ExzFt64H+804FiEQrIUFl0evg3FUfgO/6cZ4eoKn+ZKxd6L1mz0Bgei5w3aoUmC6ZhygagfDSTt93eAe0YgmQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DWF2snKT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DWF2snKT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A77F2C116C6; Tue, 13 Jan 2026 14:46:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768315568; bh=4uCAucSurgWYYIfTPVGMA7hAEuKLq8ADMBBO1vAY/Ts=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DWF2snKTTWME68p5bqRoDMZp5nz+HXJ3bikIf6obk6LehQbfcBB89unOKo0echBdQ FuaLneguObpC5wzEdpQ4rXKS7R+Ve5bjzkv3OLAU9ULW88251bOBr6hU6ADJ4kju8g Ow6/uz65FMFNWthx0KS95LsdmFZZ89cakQFpXsZjmBoc6LAFAoBEQ9+wOqAOQ4UcHj 5J6wu98pb1caihXnGjUDkQ6+uXeDHWR1nEAKf56OwSj6TZZTGkxmse0ttEsihnjDqj 6MjG+RmsooY9V3L2ZPU8Fj55ZhiqPZ64NpuhkDFoZhEoO57LJvo6aI93ajbvqAI/OW 5jmKNED0nhbOw== Date: Tue, 13 Jan 2026 16:46:01 +0200 From: Mike Rapoport To: Jason Gunthorpe Cc: Jason Miu , Alexander Graf , Andrew Morton , Baoquan He , Changyuan Lyu , David Matlack , David Rientjes , Pasha Tatashin , Pratyush Yadav , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4 1/2] kho: Adopt radix tree for preserved memory tracking Message-ID: References: <20260109001127.2596222-1-jasonmiu@google.com> <20260109001127.2596222-2-jasonmiu@google.com> <20260112143904.GA812923@nvidia.com> <20260113130526.GE812923@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260113130526.GE812923@nvidia.com> On Tue, Jan 13, 2026 at 09:05:26AM -0400, Jason Gunthorpe wrote: > On Tue, Jan 13, 2026 at 01:34:42PM +0200, Mike Rapoport wrote: > > > For example mshv intends to use kho_radix_tree to track the hypervisor > > memory and there unpreserving will be a part of the normal flow. > > I do not think this is a good idea. Sorry I wasn't clear, mshv is not going to use KHO memory tracker but another instance of kho_radix_tree data structure. I don't see a problem with that. > Nothing should be touching KHO until a kexec sequence is started. KHO > calls should WARN_ON prior to this point. If a kexec sequence aborts > then the entire radix tree should be discarded and it should go back > to WARN_ON'ing KHO calls. The whole point of making KHO stateless was to decouple it from kexec sequence and let userspace control when preservation happens and to allow preserving as much as possible ahead of time to save cycles at kexec-reboot. > Jason -- Sincerely yours, Mike.