Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp5647940ybc; Wed, 27 Nov 2019 07:19:36 -0800 (PST) X-Google-Smtp-Source: APXvYqzdoM1FZYxOC75ptqy3sx+hKC07/2bKpUebIDIiQtWEAoX7lQ2a/RlS4TfkGEvlaocNFYsb X-Received: by 2002:a17:906:49c5:: with SMTP id w5mr33994404ejv.21.1574867976730; Wed, 27 Nov 2019 07:19:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574867976; cv=none; d=google.com; s=arc-20160816; b=VM5wZALP9kv5YfeRkKF6RqH1RrFs6FFPVvWpDH3gA7rcjwrHyxX0sIBJRHTzOkYicn iKkBJbY7NDbH9DTkeEHgS5+whVwEfaJQET9VV5BtQgkklg4sX1AFcgFnp9jd33VTNaE8 SaRb3rXGmc2P6v7m0BlbTDHdQDHzvpmX/lBsTkQ55L2tmIyMW0qapiPhc+Tiz+6f/9tD JsbU9CmPRTht1txSp1a4Wj87Uj1gQNnbBDbEtafoLSMCY09HjbORAxRd5Gq5Bi0PHXGT XGsswbqGWWO1fUY5Sx2HwfbdzeVsLhheUK0jHN9AObRkml8HVDSFh3fi1qg6mhUiMN8v e70w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=xDzqAuKpsMI0fM1Nu2APkhHGF83sjAZj+b2lNk9mmCU=; b=gwBeCfkOQS3DIXSSV/A3qPdVfPxqRYLADNdqVTJ4I5uhhPeJzwU+nyMLQ/CgTEahFZ XGMoQwsnUxwaKu0BmxwWgpLB2ONEtiPbyTU3qWdcI1UvqYKSr53CS67j6tSygMktEsXu 6/+NBzjKpwT4ROknPpZdIiOL6Ki2+pYYOiWG1VPBYqXzIzVYaUWq5UUPyoPtcgZJMzks +gaDf70uR7ISirOZaTkJfXoeCDxYkjgrX2tesQtU0utOGJoCBY/qa1th+uZIhBQWufYk vUNWg53ki6uQhJjnSgNFgdRQN8mR5sNb+WxjY1+dDR9k/UkhYZHev4etF7Ah5OBDLxEy WHsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b=RElQVMX9; 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 bc12si1320321edb.12.2019.11.27.07.19.11; Wed, 27 Nov 2019 07:19:36 -0800 (PST) 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; dkim=pass header.i=@c-s.fr header.s=mail header.b=RElQVMX9; 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 S1727318AbfK0PPT (ORCPT + 99 others); Wed, 27 Nov 2019 10:15:19 -0500 Received: from pegase1.c-s.fr ([93.17.236.30]:3691 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726655AbfK0PPS (ORCPT ); Wed, 27 Nov 2019 10:15:18 -0500 Received: from localhost (mailhub1-ext [192.168.12.233]) by localhost (Postfix) with ESMTP id 47NPTZ5Z5sz9v0vn; Wed, 27 Nov 2019 16:15:14 +0100 (CET) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=RElQVMX9; dkim-adsp=pass; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id eEa3dEyy4enE; Wed, 27 Nov 2019 16:15:14 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 47NPTZ4Wzmz9v0vj; Wed, 27 Nov 2019 16:15:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1574867714; bh=xDzqAuKpsMI0fM1Nu2APkhHGF83sjAZj+b2lNk9mmCU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=RElQVMX9+cCEQ78l0/J1L3DVbJxFsc0NztZpgSERF3y/OySvGhO+jQzlTNdzWyb64 f+vTAMnbV/x1zA7L+63FgChsJ6lc31ydvuTMVMObuv0zcJFM8zhorlNmr3lRheuJgs VEUpw+GHSuU0PQLV6/W/oj5hu5sjavTHhRdzLf0o= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 253978B868; Wed, 27 Nov 2019 16:15:16 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id TiWizM8GxlXJ; Wed, 27 Nov 2019 16:15:16 +0100 (CET) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 806FA8B85A; Wed, 27 Nov 2019 16:15:15 +0100 (CET) Subject: Re: [PATCH v4 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq() To: Segher Boessenkool Cc: Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <5ca6639b7c1c21ee4b4138b7cfb31d6245c4195c.1570684298.git.christophe.leroy@c-s.fr> <877e3tbvsa.fsf@mpe.ellerman.id.au> <20191121101552.GR16031@gate.crashing.org> <87y2w49rgo.fsf@mpe.ellerman.id.au> <20191125142556.GU9491@gate.crashing.org> <5fdb1c92-8bf4-01ca-f81c-214870c33be3@c-s.fr> <20191127145958.GG9491@gate.crashing.org> From: Christophe Leroy Message-ID: <2072e066-1ffb-867e-60ec-04a6bb9075c1@c-s.fr> Date: Wed, 27 Nov 2019 16:15:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191127145958.GG9491@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 27/11/2019 à 15:59, Segher Boessenkool a écrit : > On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote: >> So what do we do ? We just drop the "r2" clobber ? > > You have to make sure your asm code works for all ABIs. This is quite > involved if you do a call to an external function. The compiler does > *not* see this call, so you will have to make sure that all that the > compiler and linker do will work, or prevent some of those things (say, > inlining of the function containing the call). But the whole purpose of the patch is to inline the call to __do_irq() in order to avoid the trampoline function. > >> Otherwise, to be on the safe side we can just save r2 in a local var >> before the bl and restore it after. I guess it won't collapse CPU time >> on a performant PPC64. > > That does not fix everything. The called function requires a specific > value in r2 on entry. Euh ... but there is nothing like that when using existing call_do_irq(). How does GCC know that call_do_irq() has same TOC as __do_irq() ? > > So all this needs verification. Hopefully you can get away with just > not clobbering r2 (and not adding a nop after the bl), sure. But this > needs to be checked. > > Changing control flow inside inline assembler always is problematic. > Another problem in this case (on all ABIs) is that the compiler does > not see you call __do_irq. Again, you can probably get away with that > too, but :-) Anyway it sees I reference it, as it is in input arguments. Isn't it enough ? Christophe