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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68365C433F5 for ; Wed, 20 Oct 2021 15:08:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C00F6128B for ; Wed, 20 Oct 2021 15:08:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230219AbhJTPKj (ORCPT ); Wed, 20 Oct 2021 11:10:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:45810 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229570AbhJTPKi (ORCPT ); Wed, 20 Oct 2021 11:10:38 -0400 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 46E9D611EF; Wed, 20 Oct 2021 15:08:24 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mdDCY-000SjC-5W; Wed, 20 Oct 2021 16:08:22 +0100 Date: Wed, 20 Oct 2021 16:08:21 +0100 Message-ID: <871r4fd996.wl-maz@kernel.org> From: Marc Zyngier To: Anup Patel Cc: Guo Ren , Samuel Holland , Atish Patra , Thomas Gleixner , Palmer Dabbelt , Heiko =?UTF-8?B?U3TDvGJuZXI=?= , Rob Herring , Linux Kernel Mailing List , linux-riscv , Guo Ren Subject: Re: [PATCH V4 1/3] irqchip/sifive-plic: Add thead,c900-plic support In-Reply-To: References: <20211016032200.2869998-1-guoren@kernel.org> <20211016032200.2869998-2-guoren@kernel.org> <8be1bdbd-365d-cd28-79d7-b924908f9e39@sholland.org> <8735oxuxlq.wl-maz@kernel.org> <875ytrddma.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: anup@brainfault.org, guoren@kernel.org, samuel@sholland.org, atish.patra@wdc.com, tglx@linutronix.de, palmer@dabbelt.com, heiko@sntech.de, robh@kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, guoren@linux.alibaba.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Oct 2021 15:33:49 +0100, Anup Patel wrote: > > On Wed, Oct 20, 2021 at 7:04 PM Marc Zyngier wrote: > > > > On Tue, 19 Oct 2021 14:27:02 +0100, > > Guo Ren wrote: > > > > > > On Tue, Oct 19, 2021 at 6:18 PM Marc Zyngier wrote: > > > > > > > > On Tue, 19 Oct 2021 10:33:49 +0100, > > > > Guo Ren wrote: > > > > > > > > > > If you have an 'automask' behavior and yet the HW doesn't record this > > > > > > in a separate bit, then you need to track this by yourself in the > > > > > > irq_eoi() callback instead. I guess that you would skip the write to > > > > > > the CLAIM register in this case, though I have no idea whether this > > > > > > breaks > > > > > > the HW interrupt state or not. > > > > > The problem is when enable bit is 0 for that irq_number, > > > > > "writel(d->hwirq, handler->hart_base + CONTEXT_CLAIM)" wouldn't affect > > > > > the hw state machine. Then this irq would enter in ack state and no > > > > > continues irqs could come in. > > > > > > > > Really? This means that you cannot mask an interrupt while it is being > > > > handled? How great... > > > If the completion ID does not match an interrupt source that is > > > currently enabled for the target, the completion is silently ignored. > > > So, C9xx completion depends on enable-bit. > > > > Is that what the PLIC spec says? Or what your implementation does? I > > can understand that one implementation would be broken, but if the > > PLIC architecture itself is broken, that's far more concerning. > > Yes, we are dealing with a broken/non-compliant PLIC > implementation. > > The RISC-V PLIC spec defines a very different behaviour for the > interrupt claim (i.e. readl(claim)) and interrupt completion (i.e. > writel(claim)). The T-HEAD PLIC implementation does things > different from what the RISC-V PLIC spec says because it will > mask an interrupt upon interrupt claim whereas PLIC spec says > it should only clear the interrupt pending bit (not mask the interrupt). > > Quoting interrupt claim process (chapter 9) from PLIC spec: > "The PLIC can perform an interrupt claim by reading the claim/complete > register, which returns the ID of the highest priority pending interrupt or > zero if there is no pending interrupt. A successful claim will also atomically > clear the corresponding pending bit on the interrupt source." > > Refer, https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc That's not the point I'm making. According to Guo, the PLIC (any implementation of it) will ignore a write to claim on a masked interrupt. If that's indeed correct, then a sequence such as: (1) irq = read(claim) (2) mask from the interrupt handler with the right flags so that it isn't done lazily (3) write(irq, claim) will result in an interrupt blocked in ack state (and probably no more interrupt for this CPU at this priority). That would be an interesting bug in the current code, but also a pretty bad architectural choice. M. -- Without deviation from the norm, progress is not possible.