Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp393968pxk; Fri, 11 Sep 2020 09:43:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0Ob9yWm9mBfxdHwoMmUhdebgGQQZXuGc5S0XW+wmY5B3yLuvlNlHV53vuyBV//+/xGX8T X-Received: by 2002:aa7:c554:: with SMTP id s20mr3042689edr.230.1599842607916; Fri, 11 Sep 2020 09:43:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599842607; cv=none; d=google.com; s=arc-20160816; b=Ghw2IizHXZFMaFF4k42E4U7k60LrUeAjqMHAdNJhgTVrJj51QfmY/yFraJlD2g8fJp WxYSad6NwZvcxjcM8TYhXL5HCAKeig3pcl4/0ZK3nx2Jv0LsQBSB31FwkdMLve9IuALF F2S4uuaGTF1Mnmeba1XiIz3jIS9nXf7ZnrQvleffAY2FUxXLJkKqR3FWNkDYwjDxli7r GKvEYB9+byBeEN5lTkEAbxmm3ZIpVVCxvF00p3UDZxlLhJOmBJP6RJ6XzZYeO3J+5Mrv YS8EKMhTL5wpHGean6MpCk90ys/C0KYtX5EHNG3/6aRbuxyqvzdUUh/d4bW0oWMQ0tgr 5BTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=sqbQHAPxZcKcXuHeUNph/9u4kJi2yD9DIZQksI5bDG8=; b=aKfMcf+nKCLocFeteUpwMhNemsLTDGnbfYIUL6/EXTdSF1GthWyspkmYcU4qhe1wEQ DgIQu/u63a6dBBcOrFr+ry23ySYdEFQ5XSh58K+EkyP0lxLxiuOsxS/YngpLcKBN1GAZ 725hoPdUebm/UNENBzEscIICXWEFKkQQIdCe2bC0QwMwHV+TmiNbzNyw6UVjpoeS/rq6 K+0hbly26/IhJRgusPGG9gRKl588ee8Ojb1YmoLG65/+yAHK0Jj/SkUh8IUZt9Hn6Fb/ vxdGHGy4/WDLUgBIziOaCwPXWEJDbRFl1cF11J4zbRcvF5NMdoSP9mT3rtyjAxUJO5S/ HGfA== 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 pj11si1577961ejb.191.2020.09.11.09.43.04; Fri, 11 Sep 2020 09:43:27 -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 S1726355AbgIKQmc (ORCPT + 99 others); Fri, 11 Sep 2020 12:42:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:49214 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726331AbgIKPKE (ORCPT ); Fri, 11 Sep 2020 11:10:04 -0400 Received: from gaia (unknown [46.69.195.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3E29E20575; Fri, 11 Sep 2020 15:05:42 +0000 (UTC) Date: Fri, 11 Sep 2020 16:05:39 +0100 From: Catalin Marinas To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Will Deacon , Russell King , Thomas Gleixner , Jason Cooper , Sumit Garg , Valentin Schneider , Florian Fainelli , Gregory Clement , Andrew Lunn , Saravana Kannan , kernel-team@android.com Subject: Re: [PATCH v3 03/16] arm64: Allow IPIs to be handled as normal interrupts Message-ID: <20200911150539.GD12835@gaia> References: <20200901144324.1071694-1-maz@kernel.org> <20200901144324.1071694-4-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200901144324.1071694-4-maz@kernel.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 01, 2020 at 03:43:11PM +0100, Marc Zyngier wrote: > In order to deal with IPIs as normal interrupts, let's add > a new way to register them with the architecture code. > > set_smp_ipi_range() takes a range of interrupts, and allows > the arch code to request them as if the were normal interrupts. > A standard handler is then called by the core IRQ code to deal > with the IPI. > > This means that we don't need to call irq_enter/irq_exit, and > that we don't need to deal with set_irq_regs either. So let's > move the dispatcher into its own function, and leave handle_IPI() > as a compatibility function. > > On the sending side, let's make use of ipi_send_mask, which > already exists for this purpose. > > One of the major difference is that we end up, in some cases > (such as when performing IRQ time accounting on the scheduler > IPI), end up with nested irq_enter()/irq_exit() pairs. > Other than the (relatively small) overhead, there should be > no consequences to it (these pairs are designed to nest > correctly, and the accounting shouldn't be off). > > Reviewed-by: Valentin Schneider > Signed-off-by: Marc Zyngier In case you need an ack for the arm64 part: Acked-by: Catalin Marinas