Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1596385ybj; Wed, 6 May 2020 01:25:50 -0700 (PDT) X-Google-Smtp-Source: APiQypKt+nay8KDWuAOTbf6THUhu5OBE2KAubkb3G6Dmx3Hcx7qbKv69ReRxg24ix+J0CdmiYXy8 X-Received: by 2002:a17:906:35d0:: with SMTP id p16mr6177170ejb.77.1588753549939; Wed, 06 May 2020 01:25:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588753549; cv=none; d=google.com; s=arc-20160816; b=IycLkgxGXjoYiEbPpolc1fZsogSPl04yxl7MP8Q1OrxCjeM3kw4DhHoW6+Urv9eAmt 3ychJPhBvT1oHv4eC84JVZmnYRoDAK6+8a1+BaQsBQP4tZv/UF8g+2bd+bwkKd6lFOA9 fVDGOtuK4E2KNsBPrnIGwoaXxzuXGx9PeBFAmT5pXxofCjk08Wr5mNHaVGTVgbgkWuEz LJJl7cAUCi75bzdpFza6rUar0lU1FL2MW5Ha0Inb0tPvloKrtHlkl+DW5A7levY5JZKw UpuMt1sY/RTU5BeDhwde1ENYN3leZW5mNDZiPxu+WLOm0o3OrIO/Ef/2IJNLvzVD5dfH Km9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=Z8BGa7cAWU1ulGJOcD4tBOfx1ywbR9rYVdgvHu6C0gE=; b=FJ/iJwtEiNJN6jtJKuh3ETb4WaU2gcsHmU7E4pMlT5vaTvgarg2+RRas71FZiV7sJj woR+zH8rKyuD83T0MLzkWz56hVKnEV7TbseJswTnf7f7Cm1I7+DgiWg3oRhO2Lvr7ds7 rTN7/OgooS6SNpdzIjZ3NJqxq7L9/ieQfjbU5FKp3UWMpBrU0FWx7D3MJ0MMwHNUiyy5 eWdeqHcCIYN+lLzgMIkKhW4A4hv149iHdzZhKcU2avbG3NyDzaHvIpJ9Ftr/aqijrmqM lMr0tmHafB7y1wWIH4NfUTCO/tqxQx0dOBLfYAqyG9NZhdPnLWdVD86SpWisJ/QPat+u Oufw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c8si606842edn.240.2020.05.06.01.25.27; Wed, 06 May 2020 01:25:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728611AbgEFIVK (ORCPT + 99 others); Wed, 6 May 2020 04:21:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728296AbgEFIVK (ORCPT ); Wed, 6 May 2020 04:21:10 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AE6EC061A0F for ; Wed, 6 May 2020 01:21:10 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jWFIJ-00078r-3P; Wed, 06 May 2020 10:20:43 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 4D7351001F5; Wed, 6 May 2020 10:20:42 +0200 (CEST) From: Thomas Gleixner To: LKML Cc: x86@kernel.org, "Paul E. McKenney" , Andy Lutomirski , Alexandre Chartre , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Steven Rostedt , Joel Fernandes , Boris Ostrovsky , Juergen Gross , Brian Gerst , Mathieu Desnoyers , Josh Poimboeuf , Will Deacon Subject: Re: [patch V4 part 5 02/31] x86/entry: Provide helpers for execute on irqstack In-Reply-To: <20200505135828.316937774@linutronix.de> References: <20200505135341.730586321@linutronix.de> <20200505135828.316937774@linutronix.de> Date: Wed, 06 May 2020 10:20:42 +0200 Message-ID: <87pnbho4o5.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner writes: > That also allows to move the xen hypercall extra magic code and the softirq > stack switching into C. > > The mechanism is straight forward: > > 1) Store the current stack pointer on top of the interrupt stack. That's > required for the unwinder. > > 2) Switch the stack pointer > > 3) Call the function > > 4) Restore the stackpointer > > The full code sequence to make the unwinder happy is: > > pushq %rbp > movq %rsp, %rbp > movq $(top_of_hardirq_stack - 8), %reg > movq %rsp, (%reg) > movq %reg , %rsp > call function > popq %rsp > leaveq > > While the following sequence would spare the 'popq %rsp': > > pushq %rbp > movq $(top_of_hardirq_stack - 8), %rbp > movq %rsp, (%rrbp) > xchgq %rbp, %rsp > call function > movq %rbp, %rsp > leaveq So I stared some more into that. The push rbp is wrong for the frame unwinder case. That one is happy (except for objtool) with the most minimalistic variant: movq %%rsp, (%[tos]) movq %[tos], %%rsp call function popq %%rsp which is not surprising because for the frame unwinder this is similar to the 'gcc aligns stack in the middle of the function' handling. BP still has to point to the previous frame. Adjustment of BP must only happen on function entry. The stack border convention of having the pointer to the previous stack in the top word is sufficient for this. objtool complains though: warning: objtool: do_softirq_own_stack()+0x67: return with modified stack frame That obviously makes also the ORC unwinder unhappty as objtool fails to provide the right hint. But also for ORC this construct should be completely sufficient. I'm exploring another idea right now, but wanted to share the info. Thanks, tglx