Received-SPF: pass (google.com: domain of linux-kernel+bounces-48792-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Michael Kelley <mhklinux@outlook.com>
To: Saurabh Sengar <ssengar@linux.microsoft.com>, "kys@microsoft.com"
	<kys@microsoft.com>, "haiyangz@microsoft.com" <haiyangz@microsoft.com>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>, "decui@microsoft.com"
	<decui@microsoft.com>, "tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, "x86@kernel.org"
	<x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>, "dwmw@amazon.co.uk"
	<dwmw@amazon.co.uk>, "peterz@infradead.org" <peterz@infradead.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
CC: "ssengar@microsoft.com" <ssengar@microsoft.com>
Subject: RE: [PATCH] x86/hyperv: Use per cpu initial stack for vtl context
Thread-Topic: [PATCH] x86/hyperv: Use per cpu initial stack for vtl context
Thread-Index: AQHaVTwzTTWwliUuVUe5IDDLZlv3X7D13i+w
Date: Thu, 1 Feb 2024 19:53:59 +0000
Message-ID:
 <SN6PR02MB415750EE9132ECB049D7B20AD4432@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <1706811931-3579-1-git-send-email-ssengar@linux.microsoft.com>
In-Reply-To: <1706811931-3579-1-git-send-email-ssengar@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?f/lqsx35OG0VNRT13AxfUhFd7wXtfPV9t5GhD/nrFKX2HWe02jVjdPXdbuUK?=
 =?us-ascii?Q?ANIID6Bg0EbgVw4COLXFUwpBTk2fW+U23D5doTdaR9H3ejsKRMvkqKh+Ju8k?=
 =?us-ascii?Q?cuY4UmojU1MruhMnPBrTEo1xxN4koEhS4cQdPVcQj/A2cqsd7qnmRsSdaF2C?=
 =?us-ascii?Q?qSmKfLHWX2hicFmWkhL+nz5z8zMZStIZMwDP8wWUiSj9EWe7Q8vu0bWPpP/j?=
 =?us-ascii?Q?/acTCnhLRstU1+bVc/uDcRstt6Xlc29H8i/MHIf16z1OzAza6op+t5T22glI?=
 =?us-ascii?Q?wtlWmcDowtDMTj/qFEVScVpJbprmqNxLtGACMWa8XLHebMlUYrDbT32SliEm?=
 =?us-ascii?Q?y/Oflc2bdewsWdRBoxULQcjhbibMbRiPSlvNIzECIVKlsWa4lfRnptD/ZVgh?=
 =?us-ascii?Q?yj29lmT6CHBjPF8fwbHzU4rphlLUuSo661cGeXsyg+dPSusZLbFpOq7bKeon?=
 =?us-ascii?Q?toygWEZwqtLtTVbkv2tZ8wNmye4CDMLpmG0oe2XrbPKzLeUZMtmdP23MTEYO?=
 =?us-ascii?Q?wVx/qDHiGto2RfObFMeU0dN7u5bf9BbOFnl/+XclBqOnPgGQyFxBcL7+a52i?=
 =?us-ascii?Q?tm7hz+n+IEN57kA4mcNtoffUSn8saqyCdbHusb69DnxfkQGQSstrMa1qm5bg?=
 =?us-ascii?Q?qi6ZYHZP0e1MSk0fL5QGphVonUKOPkMh09OQXWWJg8eKNtfRrL+hCHP0R7bf?=
 =?us-ascii?Q?HaG14t5QjYAAvT6hC5RzX8Ulz0fya2qUBnoqZ9FA1nqgnGmjDKAtIPAlmUi/?=
 =?us-ascii?Q?2CE0nas0ZcdCQfFnZWLaGTphQclVzi7pbL4UHzz1IyXXEiqH/Eso/HK1GEGJ?=
 =?us-ascii?Q?tZ6ae/grSCR3E2wXgT9mDPddoXwJUmdTWUM6W0BSYR5cdJVNPFpmRupC/Buw?=
 =?us-ascii?Q?++pr4oVbNDiF/zoqFacDYl8xM/2FZ9r/qzQ+kbRVbGx8Mbj/HYGCz7ER+qD7?=
 =?us-ascii?Q?czm9eHaXZ79hBQuI80I2M1Cny2JiV/b55b5agFZFqCasWrdxHfTKW678wYY/?=
 =?us-ascii?Q?GqHydMRW43eLOfrqvkYlyEL6ocCUVGurQEvu/bu5LZw0AJKbs78YVbj5TdQC?=
 =?us-ascii?Q?XePeqxIkZ3YuxAOzD8kdTMIqDDol5QlCmli0f83XeyOSTRK/Uu/47NhsmonO?=
 =?us-ascii?Q?AA5FEGahqCpV0MEv/anPXKBwtWXdb3mq4no68mnumpMn4EahyujUwuD6QJc7?=
 =?us-ascii?Q?OPNCT8tKz8GeuhCbcxJNftvFecohnnesfi5eHw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e98cbbc-5508-4e2b-0690-08dc235f881d
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2024 19:53:59.2071
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR02MB7055

From: Saurabh Sengar <ssengar@linux.microsoft.com> Sent: Thursday, February=
 1, 2024 10:26 AM
>=20
> Currently, the secondary vCPUs in Hyper-V VTL context lack support for
> parallel startup. Therefore, relying on the single initial_stack fetched
> from the current task structure suffices for all vCPUs.
>=20
> However, common initial_stack risks stack corruption when parallel startu=
p
> is enabled. In order to facilitate parallel startup, use the initial_stac=
k
> from the per CPU idle thread instead of the current task.
>=20
> Fixes: 18415f33e2ac ("cpu/hotplug: Allow "parallel" bringup up to CPUHP_B=
P_KICK_AP_STATE")
> Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
> ---
>  arch/x86/hyperv/hv_vtl.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>=20
> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> index 96e6c51515f5..a54b46b673de 100644
> --- a/arch/x86/hyperv/hv_vtl.c
> +++ b/arch/x86/hyperv/hv_vtl.c
> @@ -12,6 +12,7 @@
>  #include <asm/i8259.h>
>  #include <asm/mshyperv.h>
>  #include <asm/realmode.h>
> +#include <../kernel/smpboot.h>
>=20
>  extern struct boot_params boot_params;
>  static struct real_mode_header hv_vtl_real_mode_header;
> @@ -71,7 +72,8 @@ static int hv_vtl_bringup_vcpu(u32 target_vp_index, u64=
 eip_ignored)
>  	struct ldttss_desc *ldt;
>  	struct desc_struct *gdt;
>=20
> -	u64 rsp =3D current->thread.sp;
> +	struct task_struct *idle =3D idle_thread_get(target_vp_index);

The "VP index" of a vCPU is a Hyper-V concept, and may not match
the Linux concept of a CPU number.   In most cases, they *do* match,
so your testing of this patch probably worked.  But there's no guarantee
that they match.  The Hyper-V TLFS does not even guarantee that VP
indices are dense or that they start with 0 (even though they do in
current versions of Hyper-V).

As a different kind of example, in a kdump kernel, Linux labels the
booting CPU as CPU 0, but it may not be the 0th CPU in the guest
VM, and hence may not have VP index of 0.  Of course, in a kdump
kernel nr_cpus is typically 1, so you aren't bringing up secondary
CPUs.  But sometimes kdump kernels boot with nr_cpus=3D2 or greater,
in which case the mismatch would occur.

This conceptual difference in VP index and Linux CPU numbers is why
the hv_vp_index array exists -- to map from a Linux CPU number to a
Hyper-V VP index, and thereby avoid assuming they are equal.

So before hv_vtl_wakeup_secondary_cpu() calls this function, it needs
to separately map the apicid to a Linux CPU number, which can then
be passed to idle_thread_get().

Michael

> +	u64 rsp =3D (unsigned long)idle->thread.sp;
>  	u64 rip =3D (u64)&hv_vtl_ap_entry;
>=20
>  	native_store_gdt(&gdt_ptr);
> --
> 2.34.1
>=20