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 623C73EF640; Mon, 1 Jun 2026 20:15:25 +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=1780344926; cv=none; b=cysfHEFTXSX5Cx6d3YIh0izoJpVYA4UdJLgeOaQlngIpGJVYB8B1uEQ1ujR0jcAF7pbpDZWRS+EyKfYTVv+O43XfpekuP4SoG+z1pp0zF1evSRrYX3h08K1arVeJgLTmdztleDi3HyzXVyQpduoANkMvrUfHiqFHFZz7o6RSFKo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780344926; c=relaxed/simple; bh=sV59Ed4w+Eof++O+qs9Z6pjJYEeTLqX3Gwl9c7OaT1U=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=pYz3Py4+PtdwQ8bM0x95kZYTALKcWbgn/Z5lxbm9npOcGdWpUO6yaxTYoVpQAWG6pjmm+TChutfhTRE9gEccAK5PHtdsX5W+Z3cXkPWSHHoYi9Tr2badXVPegder7Z90A5BfNCMT0If3I0u6/VO6xEFckSURRaQ06GCoJACwZaY= 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=N4fFVqdp; 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="N4fFVqdp" Received: by linux.microsoft.com (Postfix, from userid 1241) id C8C6B20B7167; Mon, 1 Jun 2026 13:15:11 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C8C6B20B7167 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1780344911; bh=i8NBTcO9HEOzTK8eQah5j9/dFbH36DIcHsxmT2YF1Qc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=N4fFVqdpnNKdfAbjqncbFZwC2cL0SqneHkeBwmGFomr8pp0NRNUByLEUbqgl8CJ8N vY6qbZwhRR9MwgL5+zUBwQimuhzzrZM/WE/HOOB8z/Dme678HYaDRiKwCDmVLKYqQV OjG4scG03Yvz67ic0ko8L1MxjUf3zZKekJ1EavqM= Received: from localhost (localhost [127.0.0.1]) by linux.microsoft.com (Postfix) with ESMTP id C62FA307029C; Mon, 1 Jun 2026 13:15:11 -0700 (PDT) Date: Mon, 1 Jun 2026 13:15:11 -0700 (PDT) From: Jork Loeser To: Pasha Tatashin cc: Mike Rapoport , linux-hyperv@vger.kernel.org, linux-mm@kvack.org, kexec@lists.infradead.org, "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , 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: <4172d271-21b4-346-924e-406baef179a1@linux.microsoft.com> 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 Mon, 1 Jun 2026, Pasha Tatashin wrote: > On 05-31 20:10, Mike Rapoport wrote: >>> - 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. > > Yes, using KHO directly here is incorrect. The state machine is provided > by LUO, so we should use LUO here. MSHV should provide a file that > userspace adds to LUO, and all state machine management would be the > same as for all other clients participating in LU. The thing is, there is no file handle to rely on. Even once partitions are all removed, Hyper-V might hang onto pages (and won't return them even if asked). However, these pages very much must be excluded from Linux post-kexec, or the system will crash. We cannot rely on UM to ensure integrity of memory management. Contrast that to standard LUO use: If you drop individual file handles, or even skip the LUO phase entirely, the worst that will happen is that the objects will be gone post-kexec. The MM itself will still be consistent. For MSHV & page donation, this is different. (And yes, partition preservation will very much tie into LUO) Best, Jork