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 11694330642; Wed, 25 Feb 2026 22:28:00 +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=1772058482; cv=none; b=msc1Y/g1qRHYNhnEBhnJHxLsylkrvXe16wZ8yTrE4v0MWVmNJkm+cHA6mnG3+p0Ve5rDix1YwO6+5kmOqdcgJLRWdQyDE8+0F9MFvjlxclWgzy8AfEDraGbP5U9KjsvpHRrJldn7Y6vTdBJBGcrtDaOlin9cStnKcW8x+z+mNeM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772058482; c=relaxed/simple; bh=uZMGg6Sbk52Mepkr+C/FTt7KiuFYuuw9qSDXF9S7sv0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MemM4JV2oAc4Uri6oN/Hd2oHwoOto0FnP53k8g2Q+a1b4MYPEWx6mtoD43Hsl7Kv56Rw+6hZhztqvBlXTjmtjEa4HWJBkrohI5YbXTY6o9QO+JhXknOGjcIGiePTNMVmKhFNshx8CgPfvZ/D8VhgBvOuRsbXMh8ZsD6urF+KjRc= 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=E//yCjqu; 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="E//yCjqu" Received: from [192.168.0.88] (192-184-212-33.fiber.dynamic.sonic.net [192.184.212.33]) by linux.microsoft.com (Postfix) with ESMTPSA id 142F820B6F02; Wed, 25 Feb 2026 14:28:00 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 142F820B6F02 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1772058480; bh=jKs9O/kn+8kDs6GYjOO7oHC0D3maA5sh2FYyEo9tbuE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=E//yCjquSSKRYaxs70pr05IUqIzcVhavx9HeWgQesoC9FXfwr8rlvDNHlYlFqWj1N VkyMyCX8x/6TPOWRz5UbuQN8NWDOV2dBYGveWZxKz49G8zB/kqBrkMKxdUG42ot1bC T+O50wnZD4klTq8wvuhODQneKEq1IfYJlhFHR7Gg= Message-ID: Date: Wed, 25 Feb 2026 14:27:59 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH v1 5/6] x86/hyperv: Implement hypervisor ram collection into vmcore Content-Language: en-US To: Ard Biesheuvel , linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, Thomas Gleixner , Ingo Molnar , Borislav Petkov , dave.hansen@linux.intel.com, x86@kernel.org, "H . Peter Anvin" , Arnd Bergmann References: <20250910001009.2651481-1-mrathor@linux.microsoft.com> <20250910001009.2651481-6-mrathor@linux.microsoft.com> <38cdec03-889e-43dd-9dad-e621aba9dc8d@app.fastmail.com> From: Mukesh R In-Reply-To: <38cdec03-889e-43dd-9dad-e621aba9dc8d@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/21/26 08:43, Ard Biesheuvel wrote: > Just spotted this code in v7.0-rc > > On Wed, 10 Sep 2025, at 02:10, Mukesh Rathor wrote: > ... > >> +static asmlinkage void __noreturn hv_crash_c_entry(void) > > 'asmlinkage' means that the function may be called from another compilation unit written in assembler, but it doesn't actually evaluate to anything in most cases. Combining it with 'static' makes no sense whatsoever. 'static' means scope is limited to the file. Common in cases where function pointers are used, like here in this file way below. Like the comment says: "This is the C entry point from the asm glue code after...." IOW, called from assembly function (asm == assembly). > >> +{ >> + struct hv_crash_ctxt *ctxt = &hv_crash_ctxt; >> + >> + /* first thing, restore kernel gdt */ >> + native_load_gdt(&ctxt->gdtr); >> + >> + asm volatile("movw %%ax, %%ss" : : "a"(ctxt->ss)); >> + asm volatile("movq %0, %%rsp" : : "m"(ctxt->rsp)); >> + > > This code is truly very broken. You cannot enter a C function without a stack, and assign RSP half way down the function. Especially after allocating local variables and/or calling other functions - it may happen to work in most cases, but it is very fragile. (Other architectures have the concept of 'naked' functions for this purpose but x86 does not) Local variable refers to static bss struct. IOW, asm volatile("movq %0, %%rsp" : : "m"(ctxt->rsp)); same as: asm volatile("movq %0, %%rsp" : : "m"(&hv_crash_ctxt.rsp)); > IOW, this whole function should be written in asm. >> + asm volatile("movw %%ax, %%ds" : : "a"(ctxt->ds)); >> + asm volatile("movw %%ax, %%es" : : "a"(ctxt->es)); >> + asm volatile("movw %%ax, %%fs" : : "a"(ctxt->fs)); >> + asm volatile("movw %%ax, %%gs" : : "a"(ctxt->gs)); >> + >> + native_wrmsrq(MSR_IA32_CR_PAT, ctxt->pat); >> + asm volatile("movq %0, %%cr0" : : "r"(ctxt->cr0)); >> + >> + asm volatile("movq %0, %%cr8" : : "r"(ctxt->cr8)); >> + asm volatile("movq %0, %%cr4" : : "r"(ctxt->cr4)); >> + asm volatile("movq %0, %%cr2" : : "r"(ctxt->cr4)); >> + >> + native_load_idt(&ctxt->idtr); >> + native_wrmsrq(MSR_GS_BASE, ctxt->gsbase); >> + native_wrmsrq(MSR_EFER, ctxt->efer); >> + >> + /* restore the original kernel CS now via far return */ >> + asm volatile("movzwq %0, %%rax\n\t" >> + "pushq %%rax\n\t" >> + "pushq $1f\n\t" >> + "lretq\n\t" >> + "1:nop\n\t" : : "m"(ctxt->cs) : "rax"); >> + >> + /* We are in asmlinkage without stack frame, > > You just switched to __KERNEL_CS via the stack. compiler doesn't know that. >> hence make a C function >> + * call which will buy stack frame to restore the tss or clear PT >> entry. >> + */ > > Where does one buy a stack frame? A stack market :). Callee will create stack frame now that rsp is setup. >> + hv_crash_restore_tss(); >> + hv_crash_clear_kernpt(); >> + >> + /* we are now fully in devirtualized normal kernel mode */ >> + __crash_kexec(NULL); >> + >> + for (;;) >> + cpu_relax(); >> +} >> +/* Tell gcc we are using lretq long jump in the above function >> intentionally */ >> +STACK_FRAME_NON_STANDARD(hv_crash_c_entry); >> +