From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 247C22594B9; Mon, 1 Jun 2026 20:09:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780344596; cv=none; b=Wf4AFg3n4F4U35CB5UFQyGOTxtRvZJzX/CIGGw//7/jBxynq2BmiWOzNttii9E2PDb82R7IevZXXRE1xx3IP6Jq84doV8Pv0CJb0zOP3fNG4CJxioFa0iYPoVr5O/+zTN0/zumInyiq67G9VKBEmt2cFUa76u0eppYHMwPi5BrA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780344596; c=relaxed/simple; bh=7l4BvlJpVf3NkvTVDw8qXMvHqwBVNaAlWk6ZdVwqwEM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=Kac9PGeOcYc7PpagcEbsuEMWgvelGZ5zp9UpeCgYXFK+geLZlzBBYqZtzJOntpUninIz/QMK8Uo2lj5ed85waBRhf2Jb+PwHIvYAkH06LHG/foXf7fulKtFtL1V8ZHJI8ncerqVrnDwa4JNek7HJshSiuZxGs00DUbhd1ixJJoc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=HJp+sRV7; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="HJp+sRV7" Received: by linux.microsoft.com (Postfix, from userid 1241) id 7E93A20B7166; Mon, 1 Jun 2026 13:09:41 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7E93A20B7166 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1780344581; bh=eDXJ86FB/Xnvqi9RF8rrZVf1GrIi8kltJ1EOvKoDwfg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=HJp+sRV7Z+MPOGir5B+cVGDJgSKPlmbFixBaKBsui3oAaZjlZBs+SpoXYgUhogRkt 2V69j+/mhNBX90+hxId+3srtlmItfZ4xvOVH6zQix9CSW4B3cF4dMKO1vETTdCKdTk t0hko/RYjtgxX/S0C1zWqVZwqNlBNpYmi1ctKyps= Received: from localhost (localhost [127.0.0.1]) by linux.microsoft.com (Postfix) with ESMTP id 7B665307029C; Mon, 1 Jun 2026 13:09:41 -0700 (PDT) Date: Mon, 1 Jun 2026 13:09:41 -0700 (PDT) From: Jork Loeser To: Mike Rapoport cc: linux-hyperv@vger.kernel.org, linux-mm@kvack.org, kexec@lists.infradead.org, "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Pasha Tatashin , Pratyush Yadav , Alexander Graf , Jason Miu , Andrew Morton , David Hildenbrand , Muchun Song , Oscar Salvador , Baoquan He , Catalin Marinas , Will Deacon , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Kees Cook , Ran Xiaokai , Justinien Bouron , Sourabh Jain , Pingfan Liu , "Rafael J. Wysocki" , Mario Limonciello , linux-arm-kernel@lists.infradead.org, x86@kernel.org, linux-kernel@vger.kernel.org, Michael Kelley Subject: Re: [RFC PATCH 00/20] mshv: enable kexec with Hyper-V donated pages and partitions In-Reply-To: Message-ID: References: <20260528004204.1484584-1-jloeser@linux.microsoft.com> Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed On Sun, 31 May 2026, Mike Rapoport wrote: > Hi Jork, >> - A freeze mechanism to lock the tree before serializing for kexec >> (patch 13). > > There were a lot of effort to make KHO stateless and drop the requirement > for finalization/freeze. > > Why is this necessary to add a freeze mechanism to kho_radix_tree? > If it's a hard requirement of mshv maybe the freeze part should be handled > there? Good feedback. It's a safety-net so we do not accidentally donate pages without being able to track them. Thought it might be a good generic feature. Let me keep it in the MSHV driver. >> Patch 13: Radix tree freeze and del_key() error reporting > > del_key() error reporting sounds like something we'd want to avoid. > del_key() is called on "freeing" path and during error handling, it would > be hard if at all possible to deal with errors from del_key(). I hear you. Stating "yeah, it can only really fail if the key isn't there, or it's frozen, but not due to other things, so don't bother to check the return code if you are sure" is an odd contract. With the freeze-logic moving into MSHV, will revert to no-error. >> Patch 19: Export kexec_in_progress for modules > > Isn't there another way to differentiate kexec reboot? I could not find one, unfortunately. > Sincerely yours, > Mike. Best, Jork