Received: by 2002:a25:d783:0:0:0:0:0 with SMTP id o125csp488071ybg; Thu, 19 Mar 2020 03:32:44 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt66RXWyGefHQsnwYm8vhe1nzDPcYoXRyyGvUJXGVgPB4yITuOk4mK090z1hvWZxsnKw6XI X-Received: by 2002:aca:dc45:: with SMTP id t66mr1819722oig.39.1584613964096; Thu, 19 Mar 2020 03:32:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584613964; cv=none; d=google.com; s=arc-20160816; b=xrBffZjNUMw922VVZ0G/WoexkxEslWHfssrzf0fhNNU/YdV1/JwTIhdHlGqPV6RZC3 S02Se+H3VVi1PefD5jAaEkDnFy7SS+vWKerKa9OVw/k7CVOC5bRNaEok3gP+tF8UKnai yLGxrkBaic86W8fMAh/3OfcWVbevBEQH07WZ5AHm9MjJ56kAy7msciDpGTfujI8pmWBu Lhur8F+no3TwEdsRkkCkIrFH61FQRgnFIpfkR3doc45YCTBfOx7K3wGKcBkQB2XbwUfu 9HNrpPPtwErT7subif/C8fC11OkyXjmj3Q8dnUYNzG4nzLomW2IfE+qllIPCBeO93e/h CoJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=KTKOKkIemyfqbZwWrUgvjHKGwamuYQlAl4XZJVn7l8U=; b=fgpGZ1YjeLrc3+T0SbeHNE6RJu7E9F6oupwUoUA0wELjzDK+1MDXj5Vj+LlxC2Wzko y6OSGWD8P3Y+Bnr0X4rmSaL74f9g8e+p+zM3V0bbNc9LQF9cg0KScdB2bUZX4ugvDsLe jiIl1g/foKw/pN3oQIAegY5o+N4geGchZECSnPm5xrBJO7ALFBd81OPhwP2vj8n3Nj4G XAAO+xs5qFVbguMAojvu3OFbcxBhA6wxWQ/6RajhVMZmxb9XOzjm5OfbWFKlXaiSyw8E oe3qtKr8RXCnHoJVLXJ8Al9yUrnXa9ekLpNYp7NSfOmWBfydFJHs5auQTJGAudCKI9/0 eAmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m20si1128693otf.46.2020.03.19.03.32.20; Thu, 19 Mar 2020 03:32:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727162AbgCSKbV (ORCPT + 99 others); Thu, 19 Mar 2020 06:31:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:56756 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726589AbgCSKbV (ORCPT ); Thu, 19 Mar 2020 06:31:21 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 44D14B197; Thu, 19 Mar 2020 10:31:19 +0000 (UTC) Date: Thu, 19 Mar 2020 11:31:18 +0100 (CET) From: Miroslav Benes To: Jan Beulich cc: boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, jpoimboe@redhat.com, andrew.cooper3@citrix.com, x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, xen-devel@lists.xenproject.org, jslaby@suse.cz Subject: Re: [PATCH v2 1/2] x86/xen: Make the boot CPU idle task reliable In-Reply-To: <71c4eeaf-958a-b215-3033-c3e0d74a9cfa@suse.com> Message-ID: References: <20200319095606.23627-1-mbenes@suse.cz> <20200319095606.23627-2-mbenes@suse.cz> <71c4eeaf-958a-b215-3033-c3e0d74a9cfa@suse.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Mar 2020, Jan Beulich wrote: > On 19.03.2020 10:56, Miroslav Benes wrote: > > The unwinder reports the boot CPU idle task's stack on XEN PV as > > unreliable, which affects at least live patching. There are two reasons > > for this. First, the task does not follow the x86 convention that its > > stack starts at the offset right below saved pt_regs. It allows the > > unwinder to easily detect the end of the stack and verify it. Second, > > startup_xen() function does not store the return address before jumping > > to xen_start_kernel() which confuses the unwinder. > > > > Amend both issues by moving the starting point of initial stack in > > startup_xen() and storing the return address before the jump, which is > > exactly what call instruction does. > > > > Signed-off-by: Miroslav Benes > > --- > > arch/x86/xen/xen-head.S | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S > > index 1d0cee3163e4..edc776af0e0a 100644 > > --- a/arch/x86/xen/xen-head.S > > +++ b/arch/x86/xen/xen-head.S > > @@ -35,7 +35,11 @@ SYM_CODE_START(startup_xen) > > rep __ASM_SIZE(stos) > > > > mov %_ASM_SI, xen_start_info > > - mov $init_thread_union+THREAD_SIZE, %_ASM_SP > > +#ifdef CONFIG_X86_64 > > + mov initial_stack(%rip), %_ASM_SP > > +#else > > + mov pa(initial_stack), %_ASM_SP > > +#endif > > If you need to distinguish the two anyway, why not use %rsp and > %esp respectively? I could, I just preferred the unification instead. Will change it if you think it would be better. Miroslav