From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2461EC433DF for ; Thu, 2 Jul 2020 13:49:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E9BEF207D4 for ; Thu, 2 Jul 2020 13:49:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YdV1c0S5"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ay2vfvlw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E9BEF207D4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=74RIMqqKobyr7scAK02Dokf9oj9+6vZhvnVAV6IN2pQ=; b=YdV1c0S5K1fkr/X2P3smRjWs8 QS3fw0OXrSNP/FeqHOzaWsr1FkF5xJbRXAaCDfAB6GL1e0isX9LoHY5Lx6lyVzk093ko57tnzkre2 bx0EsT6eEjv0Pwvga5VD3JsANm+0mMqjD3na+o57v1tMPhcjWIguAi+KD+NDzCnS790/uQb/TvOVK 6pihC67XV+/PSfbxzF/47qdZCfQCJX//ShpbY01UWHYPyE705Kk6Dq0euC6L3eNVQ1YN/v7YTsWq0 wp46PZaeBewJ49u77JP9RFeXGJwOnv0slB8dbLLCb5zL92Z+pa22shvt09Y2IMWt4xITm70YKBu8r zr/gdiR/w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqzZu-00009X-CA; Thu, 02 Jul 2020 13:48:38 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqzZs-00008k-AR for linux-arm-kernel@lists.infradead.org; Thu, 02 Jul 2020 13:48:37 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 90487207D4; Thu, 2 Jul 2020 13:48:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593697715; bh=tMT/0/rWJ4mOlBloPAfcxWTRK0Bw2NaOowE/acDSAtw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ay2vfvlwROBwHeQy4Mn+6qoiF4tF9B477V1+7ICkTcE41dA8y22/vIFebFAuJ1JsE aq/MC52NhMc0fcocodpQAqzef8EKOe7hIQFNdvUfXPNqHw+I5/KevedfJlGWps6FZd 5vVID4duEyxGbCWCdjqh9y8FkabfAig4OEMN5DYk= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jqzZq-008Q8V-5U; Thu, 02 Jul 2020 14:48:34 +0100 MIME-Version: 1.0 Date: Thu, 02 Jul 2020 14:48:34 +0100 From: Marc Zyngier To: Valentin Schneider Subject: Re: [PATCH v2 06/17] irqchip/gic-v3: Configure SGIs as standard interrupts In-Reply-To: References: <20200624195811.435857-1-maz@kernel.org> <20200624195811.435857-7-maz@kernel.org> User-Agent: Roundcube Webmail/1.4.5 Message-ID: <1f3ac757acd15f6804917e222194c9cf@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, linux@arm.linux.org.uk, tglx@linutronix.de, jason@lakedaemon.net, sumit.garg@linaro.org, f.fainelli@gmail.com, gregory.clement@bootlin.com, andrew@lunn.ch, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200702_094836_536464_F7A2B8CF X-CRM114-Status: GOOD ( 16.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sumit Garg , Florian Fainelli , Russell King , Jason Cooper , kernel-team@android.com, Andrew Lunn , Catalin Marinas , Gregory Clement , linux-kernel@vger.kernel.org, Thomas Gleixner , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-07-02 14:23, Valentin Schneider wrote: > On 30/06/20 11:15, Marc Zyngier wrote: >> On 2020-06-25 19:25, Valentin Schneider wrote: >>> Also, while staring at this it dawned on me that IPI's don't need the >>> eoimode=0 isb(): due to how the IPI flow-handler is structured, we'll >>> get a >>> gic_eoi_irq() just before calling into the irqaction. Dunno how much >>> we >>> care about it. >> >> That's interesting. This ISB is a leftover from the loop we had before >> the pseudo-NMI code, where we had to make sure the write to EOIR was >> ordered with the read from IAR. >> >> Given that we have an exception return right after the interrupt >> handling, I *think* we could get rid of it (but that would need >> mode checking on broken systems such as TX1...). I don't think >> this is specific to IPIs though. >> > > If I got this one right: > > 39a06b67c2c1 ("irqchip/gic: Ensure we have an ISB between ack and > ->handle_irq") > > you're describing case 2, which is indeed gone on gic-v3. However IIUC > we > also want an ISB between poking IAR and calling into the irqaction > (case 1) > - we get just that with IPIs due to the early gic_eoi_irq(), but we > don't > for the other flows. You just made me realise something amazing: I've started to forget about all this crap. Which is wonderful! ;-) More seriously, you are absolutely right. If we wanted to address this, we'd probably have to give IPIs their own irqchip so that they get their own eoi callback. Not sure that's worth it. M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel