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 3BE8326ED3F for ; Sat, 28 Feb 2026 16:41:17 +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=1772296877; cv=none; b=cnhzmzk0YYlXYbUG7MpSbMtdOh+6HhOHrR0XhjbXo8OqG/uKHqmW+cVwWzR3VgHiXgi2bOUb13DwFDG1a4REVbLeSEaY5C0OhX61IAidWPEZ6P08gy48fNzb0fV6CzKLoWfa+123l7F7gYF4Rkl1xxeyB8Z/H2LI7Y/l1BuO3+c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772296877; c=relaxed/simple; bh=vNpaSDYpd9w1K/bZT8htDFDgOc5/vHZmU9FD3I1Dnbs=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=tpG1hWcCKlv/peW2bliRpy4t90suWHNSLORFL67edJ3J3ziakb+MWaM2mhPmyG+bHojCgfXNEjEWZvVrCtcp0ilGWEttUZN5akC6iKt9KYMQEym9J4cMp1jCRheD/Kkvzb0J9CcERe/EWhwnupLQirU1pAqjLkNwbS5zZiX3K+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IXPalgdv; 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="IXPalgdv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5D33C116D0; Sat, 28 Feb 2026 16:41:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772296877; bh=vNpaSDYpd9w1K/bZT8htDFDgOc5/vHZmU9FD3I1Dnbs=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=IXPalgdvrCE1Zoa6EWWFaHemQkvG+2XDfSoPvK7I6EVrHWWN/vqY2c8JcK2FcpJcC 6aZJ28JVPJwgLCcGhw8U08tRcux/TCl6Fliw/Gh0mqydVOpcqsyWcx80r+3/0h6fkX faYglLANuRTlmOotzt/YxNugv2yQP7k6KRo4msoyZAYFcCOursHQFJTjPJ3ea7+ySl Zj7+7EI71y/zzFmAYGXYNKB0ayt2c0LyDHTYmq1Pj3Y0rFyJ1f30C0+SjdbEMFvWAh VlADDXb8LtlteyIR+pmauyV7Sy6ni9SyX9fYe6rAOjSDNxJOweNyZwHFTFpe7UOc32 lYfUwettMfqfg== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id C067CF4008C; Sat, 28 Feb 2026 11:41:15 -0500 (EST) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-01.internal (MEProxy); Sat, 28 Feb 2026 11:41:15 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvhedvfeekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedftehrugcu uehivghshhgvuhhvvghlfdcuoegrrhgusgeskhgvrhhnvghlrdhorhhgqeenucggtffrrg htthgvrhhnpeeuteeiudeigeekjedvheduieehteetgfdtuefghfejgffhfedtleehvdeh fffhvdenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpe grrhguodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduieejtdehtddtjeel qdeffedvudeigeduhedqrghruggspeepkhgvrhhnvghlrdhorhhgseifohhrkhhofhgrrh gurdgtohhmpdhnsggprhgtphhtthhopeejpdhmohguvgepshhmthhpohhuthdprhgtphht thhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtoh epuhgsihiijhgrkhesghhmrghilhdrtghomhdprhgtphhtthhopeifvghirdhlihhusehk vghrnhgvlhdrohhrghdprhgtphhtthhopeigkeeisehkvghrnhgvlhdrohhrghdprhgtph htthhopehmrhgrthhhohhrsehlihhnuhigrdhmihgtrhhoshhofhhtrdgtohhmpdhrtghp thhtoheplhhinhhugidqhhihphgvrhhvsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtg hpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: ice86485a:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id A41F6700065; Sat, 28 Feb 2026 11:41:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: A_ejbntDxbYw Date: Sat, 28 Feb 2026 17:40:55 +0100 From: "Ard Biesheuvel" To: "Uros Bizjak" Cc: linux-kernel@vger.kernel.org, x86@kernel.org, "Mukesh Rathor" , "Wei Liu" , "Andrew Cooper" , linux-hyperv@vger.kernel.org Message-Id: <7c7cd72e-fd46-4f77-8bf7-8d538fec0a52@app.fastmail.com> In-Reply-To: References: <20260227224030.299993-2-ardb@kernel.org> Subject: Re: [PATCH v2] x86/hyperv: Use __naked attribute to fix stackless C function Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 28 Feb 2026, at 11:17, Uros Bizjak wrote: > On Fri, Feb 27, 2026 at 11:40=E2=80=AFPM Ard Biesheuvel wrote: >> >> hv_crash_c_entry() is a C function that is entered without a stack, >> and this is only allowed for functions that have the __naked attribut= e, >> which informs the compiler that it must not emit the usual prologue a= nd >> epilogue or emit any other kind of instrumentation that relies on a >> stack frame. >> >> So split up the function, and set the __naked attribute on the initial >> part that sets up the stack, GDT, IDT and other pieces that are needed >> for ordinary C execution. Given that function calls are not permitted >> either, use the existing long return coded in an asm() block to call = the >> second part of the function, which is an ordinary function that is >> permitted to call other functions as usual. >> >> Cc: Mukesh Rathor >> Cc: Wei Liu >> Cc: Uros Bizjak >> Cc: Andrew Cooper >> Cc: linux-hyperv@vger.kernel.org >> Fixes: 94212d34618c ("x86/hyperv: Implement hypervisor RAM collection= into vmcore") >> Signed-off-by: Ard Biesheuvel >> --- >> v2: apply some asm tweaks suggested by Uros and Andrew >> >> arch/x86/hyperv/hv_crash.c | 79 ++++++++++---------- >> 1 file changed, 41 insertions(+), 38 deletions(-) >> >> diff --git a/arch/x86/hyperv/hv_crash.c b/arch/x86/hyperv/hv_crash.c >> index 92da1b4f2e73..1c0965eb346e 100644 >> --- a/arch/x86/hyperv/hv_crash.c >> +++ b/arch/x86/hyperv/hv_crash.c >> @@ -107,14 +107,12 @@ static void __noreturn hv_panic_timeout_reboot(= void) >> cpu_relax(); >> } >> >> -/* This cannot be inlined as it needs stack */ >> -static noinline __noclone void hv_crash_restore_tss(void) >> +static void hv_crash_restore_tss(void) >> { >> load_TR_desc(); >> } >> >> -/* This cannot be inlined as it needs stack */ >> -static noinline void hv_crash_clear_kernpt(void) >> +static void hv_crash_clear_kernpt(void) >> { >> pgd_t *pgd; >> p4d_t *p4d; >> @@ -125,6 +123,25 @@ static noinline void hv_crash_clear_kernpt(void) >> native_p4d_clear(p4d); >> } >> >> + >> +static void __noreturn hv_crash_handle(void) >> +{ >> + hv_crash_restore_tss(); >> + hv_crash_clear_kernpt(); >> + >> + /* we are now fully in devirtualized normal kernel mode */ >> + __crash_kexec(NULL); >> + >> + hv_panic_timeout_reboot(); >> +} >> + >> +/* >> + * __naked functions do not permit function calls, not even to __alw= ays_inline >> + * functions that only contain asm() blocks themselves. So use a mac= ro instead. >> + */ >> +#define hv_wrmsr(msr, val) \ >> + asm("wrmsr" :: "c"(msr), "a"((u32)val), "d"((u32)(val >> 32))= : "memory") > > This one should be defined as "asm volatile", otherwise the compiler > will remove it (it has no outputs used later in the code!). An asm() block with only input operands does not need to be marked as vo= latile to prevent it from being optimized away. > Also, it > should be defined as "asm volatile" when it is important that the insn > stays where it is, relative to other "asm volatile"s. Otherwise, the > compiler is free to schedule other insns, including other "asm > volatile"s around . Since this macro is also used to update > MSR_GS_BASE (so it affects memory in case of %gs prefixed access), > "memory" clobber should remain). > All the other asm() blocks except the last one read from memory, and hv_= msr() has a memory clobber. So I don't think there is any legal transfor= mation that the compiler might apply except perhaps re-ordering it with = the final asm() block doing the long return. So I don't see any reason for volatile on hv_msr(). However, I do see a = potential issue with the compiler assuming that code after the final asm= () block is reachable, and calling unreachable() is not permitted [by Cl= ang] due to the __naked attribute. Would it be better to add a memory clobber to that one as well?