From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 748B912CDA5; Wed, 27 May 2026 23:17:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779923862; cv=none; b=PFciLm+e+SBs/Ek3uJbcEH336YvHeKtvnoJ6XOwP0bKLtZ2O253FSA6Qz/3W/qsoxgSPZRFognCqDX4C66U3vQ4eKSlakqBGqzoDSGeZrTeMg/Ff9Cb56uiBQq+NZ7Hc+O9L9y6jDCRh+I5pUg/u+W/HLhnVWWGBw7zqtqJtyB0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779923862; c=relaxed/simple; bh=CZ9SgH4iIizukUaWigKStqHzQdgwqPBo1duJe5NLhCI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IZK7hdy58ugxgaGMMayP0+ndHE71PhORiqs4AHq5AHQxrbAzGDkWKikh9D4fmz6jRA2zRl3ecl0icBNQfO4HYoQUbHYOzj3iCEwa0SvRR3jTvWHPJvYN0GZbD8DyqYjfqQXbY3TnMuZw6t4av9RXEo5zGhtMyVPLW+5cq5b9Is0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LeLfEwA5; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LeLfEwA5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 105B71F000E9; Wed, 27 May 2026 23:17:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779923861; bh=Zb9tzaSppYJ5lTPKCwIdw1KJepg0Vogvwm6Ghu1mYEA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=LeLfEwA5nWeC4m+SCGm/zRgM6ylE45Ou+venRsXpn0lmrJ+sx1NGE1v/VNzVzLz/j pnp3XuaAoI8xj4h3aIHivij8/NEiNKFSNKjJ9OTwaqRAvJhDvetxlXGiVx7naMDn9a PnV9IxQ4QQfyVVQyApyV3mtKxtB4W5s6dNznqF+E1FTGLrEJ+B3O72HAzgqw4s3rye ub8aaQhac7jIyz46BEaTxq7astDzfcjep9T44RgXUlOiH7GNxVENDaHRsJfe1nQGNR uQSuTXKPO5ConikzW0fjRg/E8an5vxq2KLiU4ZCOL2b5bVOIwfIaHCGifYCZitREoY Dv69BGLsD+fkw== Date: Wed, 27 May 2026 16:17:39 -0700 From: Wei Liu To: Michael Kelley Cc: Jork Loeser , "linux-hyperv@vger.kernel.org" , "x86@kernel.org" , "K . Y . Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Arnd Bergmann , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , Anirudh Rayabharam , Stanislav Kinsburskii , Mukesh Rathor Subject: Re: [PATCH v3 3/6] x86/hyperv: Skip LP/VP creation on kexec Message-ID: <20260527231739.GH3518940@liuwe-devbox-debian-v2.local> References: <20260408013645.286723-1-jloeser@linux.microsoft.com> <20260408013645.286723-4-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 Content-Disposition: inline In-Reply-To: On Mon, May 04, 2026 at 03:09:21PM +0000, Michael Kelley wrote: > From: Jork Loeser Sent: Tuesday, April 7, 2026 6:37 PM > > > > After a kexec the logical processors and virtual processors already > > exist in the hypervisor because they were created by the previous > > kernel. Attempting to add them again causes either a BUG_ON or > > corrupted VP state leading to MCEs in the new kernel. > > > > Add hv_lp_exists() to probe whether an LP is already present by > > calling HVCALL_GET_LOGICAL_PROCESSOR_RUN_TIME. When it succeeds the > > LP exists and we skip the add-LP and create-VP loops entirely. > > > > Also add hv_call_notify_all_processors_started() which informs the > > hypervisor that all processors are online. This is required after > > adding LPs (fresh boot) and is a no-op on kexec since we skip that > > path. > > Adding hv_call_notify_all_processors_started() seems like it should be > a separate patch. And this paragraph in the commit message leaves me > with questions: Is it really "required"? If it is, how does the existing > upstream code ever work? Does the change need to be backported > to stable kernels? If it isn't *really* required, what are the implications > of not doing it? It is complicated. If I remember correctly, we realized this call was absolutely needed if SEV-SNP host side support is enabled. If that support is not enabled, then things continue to work. I think it is the right thing to do to always make this call. We don't need to backport this yet. Wei