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=-2.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 08007C433E1 for ; Fri, 12 Jun 2020 16:57:27 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 D100120835 for ; Fri, 12 Jun 2020 16:57:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="a2vVpKpZ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dX91GOcM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D100120835 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=u3smLkeO4dbbIxmCXh/ze6uaCC9TZjhf34Xta3XvHSQ=; b=a2vVpKpZgS+Nl/ ZfnQwFsguarVkyhuIUcVgJjQE+m3uptnOFpBUtyfwm9oY6OQgNF8rhJVZ07lt5s0KQV4taBnWN7Nm 9hd/xiUx28ywHNnUCMhcYxxgYOwKhWJo4F3AQmLn3BBL+aI5VPnuuO68cwQZBb5c0iEbkvfnqlPq6 4fGh2EytBPUX++NlInE+S7PPiOrs25a+lAsQSc9f/SuL4L2SdncpDHz+GafmmCP02IUHI1GWbfh/T pcF0OEiDU1tktPNfDiqfAQCI2DVEnfGbqEgWYLBCjeSoLs/KuVgTejwKKkCU2ateXZ/i/rwhUC5V/ 4u4CpSKWKkQMDbJxnBbw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jjmze-0000yJ-20; Fri, 12 Jun 2020 16:57:26 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jjmza-0000xq-Ij for linux-arm-kernel@lists.infradead.org; Fri, 12 Jun 2020 16:57:24 +0000 Received: by mail-wr1-x444.google.com with SMTP id q11so10446296wrp.3 for ; Fri, 12 Jun 2020 09:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hdftdNmWNoYmI9KOCEdF8TYF1SQt9boCMGPOgmJ5aMc=; b=dX91GOcMpW17ERW/nwCFP38SsYVXilVSIcTeNTtYN2smr2Rcg4eXcMZvw1rl62ZyBc rTFpJX1DqOFgImEcxpGnYl+l+ssxPce1MlL3+MAyPh3qGz2hxrSW+XYBIf/idOhlp1SS VAv992HGJjQOtLagc1cesdCgFGhNue5vvBsPVlu3N9TjW3Gvtfn1/MtAW39ZZYNSHJCc J02akL1SvACXIS0D2bTdYVe+HdY+Z/0W2CkCSmCbfPqyfPafKf5R+YKgGOYZ4t2f9vNB FsLda7913vY5QR0YdtdnaPeaoMSf3ao7GZ8zXVeqIOE69heJeBx7NlDWVfFWzMzjTxfb wZnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hdftdNmWNoYmI9KOCEdF8TYF1SQt9boCMGPOgmJ5aMc=; b=Byc2TkeKzUggSpNrRG1O8en2J4nSeFkyIY39UzYr0Wd8jwzqOlZYkrAPlNYuR+dqnL gK5TTTUnvvH8YFMhik4/k1ZTH/puLMGAqLckkO5D1LXAxdGbR+4yLQTTgtw0LYHYYL1w gpENQQhQfk42AJUE76dqH9h4ArVjtsKt2fxbiqvNusU4Co3+5JHnc5OH/wmn3+yMFrez /UdSLL+x9OxKoCnt2xLy4nNnnjwpEIBDWK04GnD2y9UsoXf8Fuz0KoepT+7w5SHVuY0Y byzz7blb7hPuqYXTcb+oEnVMbcDPqXhGxCfPl9h5W44xGE/a7aKV+7cF916xBe44onQa qLug== X-Gm-Message-State: AOAM533ng1Do9rSVqmM7o8dQ4J3ecznyij22tKMfFE7gHMlDffUefZPs 1mLUpFv/0DbkfONNP8l8328= X-Google-Smtp-Source: ABdhPJyNmXM4qc3epdwtYo7bfs1VS3PSIkiDLC+pYnmFfKcklyuurpjoWjZQBuTaqU080fJh/c4sqQ== X-Received: by 2002:adf:c391:: with SMTP id p17mr15094247wrf.243.1591981040526; Fri, 12 Jun 2020 09:57:20 -0700 (PDT) Received: from [192.168.1.3] (ip68-111-84-250.oc.oc.cox.net. [68.111.84.250]) by smtp.gmail.com with ESMTPSA id b201sm9481064wmb.36.2020.06.12.09.57.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 09:57:19 -0700 (PDT) Subject: Re: [PATCH 00/11] arm/arm64: Turning IPIs into normal interrupts To: Marc Zyngier References: <20200519161755.209565-1-maz@kernel.org> <20200612104918.3829bb26@why> From: Florian Fainelli Message-ID: <0acfca3f-38fb-774c-aaab-53bc8cdbd13b@gmail.com> Date: Fri, 12 Jun 2020 09:57:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612104918.3829bb26@why> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200612_095722_671058_126CA129 X-CRM114-Status: GOOD ( 21.34 ) 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 , Russell King , Jason Cooper , Will Deacon , Catalin Marinas , linux-kernel@vger.kernel.org, Thomas Gleixner , kernel-team@android.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 6/12/2020 2:49 AM, Marc Zyngier wrote: > Hi Florian, > > On Tue, 19 May 2020 10:50:46 -0700 > Florian Fainelli wrote: > >> On 5/19/2020 9:17 AM, Marc Zyngier wrote: >>> For as long as SMP ARM has existed, IPIs have been handled as >>> something special. The arch code and the interrupt controller exchange >>> a couple of hooks (one to generate an IPI, another to handle it). >>> >>> Although this is perfectly manageable, it prevents the use of features >>> that we could use if IPIs were Linux IRQs (such as pseudo-NMIs). It >>> also means that each interrupt controller driver has to follow an >>> architecture-specific interface instead of just implementing the base >>> irqchip functionnalities. The arch code also duplicates a number of >>> things that the core irq code already does (such as calling >>> set_irq_regs(), irq_enter()...). >>> >>> This series tries to remedy this on arm/arm64 by offering a new >>> registration interface where the irqchip gives the arch code a range >>> of interrupts to use for IPIs. The arch code requests these as normal >>> interrupts. >>> >>> The bulk of the work is at the interrupt controller level, where all 3 >>> irqchips used on arm64 get converted. >>> >>> Finally, the arm64 code drops the legacy registration interface. The >>> same thing could be done on 32bit as well once the two remaining >>> irqchips using that interface get converted. >>> >>> There is probably more that could be done: statistics are still >>> architecture-private code, for example, and no attempt is made to >>> solve that (apart from hidding the IRQs from /proc/interrupt). >>> >>> This has been tested on a bunch of 32 and 64bit guests. >> >> Does this patch series change your position on this patch series >> >> https://lore.kernel.org/linux-arm-kernel/20191023000547.7831-3-f.fainelli@gmail.com/T/ >> >> or is this still a no-no? > > I don't think this series changes anything. There is no easy way to > reserve SGIs in a way that would work for all combination of OS and FW, > and the prospect of sending SGIs between S and NS has already been > dubious (yes, the GIC architecture allows it, but it has been written > by people who have never designed any large piece of SW). That is fair enough, we have transitioned since then to using SPIs and that appears to work nicely for what we want to do without requiring your patch series. In premise it is still possible for someone to specify 0x561 as the first interrupt cell specifier in the Device Tree in order to specify a SGI interrupt and this will happily be parsed as a valid interrupt. It would most likely fail some time later while trying to set the interrupt type though. I do not think you can do better than this, as there is no way for you to know the caller of gic_irq_domain_translate() and reject them. -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel