All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: will@kernel.org, robin.murphy@arm.com, kevin.tian@intel.com,
	joro@8bytes.org, praan@google.com, kees@kernel.org,
	baolu.lu@linux.intel.com, miko.lenczewski@arm.com,
	smostafa@google.com, linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, jamien@nvidia.com
Subject: Re: [PATCH v5 3/6] iommu/arm-smmu-v3: Suppress EVTQ/PRIQ events in kdump kernel
Date: Tue, 19 May 2026 19:27:49 -0300	[thread overview]
Message-ID: <20260519222749.GL3602937@nvidia.com> (raw)
In-Reply-To: <agzEVS5SFKHPb6/u@Asurada-Nvidia>

On Tue, May 19, 2026 at 01:13:09PM -0700, Nicolin Chen wrote:
> On Tue, May 19, 2026 at 02:44:53PM -0300, Jason Gunthorpe wrote:
> > On Sun, May 10, 2026 at 02:23:02PM -0700, Nicolin Chen wrote:
> > > @@ -2364,6 +2364,14 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
> > >  	static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
> > >  				      DEFAULT_RATELIMIT_BURST);
> > >  
> > > +	/*
> > > +	 * A combined IRQ might call into this function with the queue disabled.
> > > +	 * E.g. kdump, where stale HW PROD vs SW CONS would drive a bogus drain
> > > +	 * and a CONS write to a disabled queue.
> > > +	 */
> > > +	if (!(readl_relaxed(smmu->base + ARM_SMMU_CR0) & CR0_EVTQEN))
> > > +		return IRQ_NONE;
> > 
> > I don't think we should be doing register reads on these paths. 
> > 
> > Why not load a different irq function instead?
> 
> Yea. Perhaps we could even entirely skip their IRQ requests. Only
> gerror should be kept in kdump case.

Yeah, if the irq handlers don't do anything then don't register them
makes alot of sense..

Jason

  reply	other threads:[~2026-05-19 22:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-10 21:22 [PATCH v5 0/6] iommu/arm-smmu-v3: Fix device crash on kdump kernel Nicolin Chen
2026-05-10 21:23 ` [PATCH v5 1/6] iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump Nicolin Chen
2026-05-19 17:10   ` Jason Gunthorpe
2026-05-19 18:11     ` Nicolin Chen
2026-05-10 21:23 ` [PATCH v5 2/6] iommu/arm-smmu-v3: Implement is_attach_deferred() " Nicolin Chen
2026-05-19 17:43   ` Jason Gunthorpe
2026-05-10 21:23 ` [PATCH v5 3/6] iommu/arm-smmu-v3: Suppress EVTQ/PRIQ events in kdump kernel Nicolin Chen
2026-05-19 17:44   ` Jason Gunthorpe
2026-05-19 20:13     ` Nicolin Chen
2026-05-19 22:27       ` Jason Gunthorpe [this message]
2026-05-10 21:23 ` [PATCH v5 4/6] iommu/arm-smmu-v3: Skip EVTQ/PRIQ setup " Nicolin Chen
2026-05-19 17:45   ` Jason Gunthorpe
2026-05-10 21:23 ` [PATCH v5 5/6] iommu/arm-smmu-v3: Retain CR0_SMMUEN during kdump device reset Nicolin Chen
2026-05-10 21:23 ` [PATCH v5 6/6] iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP_ADOPT in probe() Nicolin Chen
2026-05-19 17:58   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260519222749.GL3602937@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jamien@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kees@kernel.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miko.lenczewski@arm.com \
    --cc=nicolinc@nvidia.com \
    --cc=praan@google.com \
    --cc=robin.murphy@arm.com \
    --cc=smostafa@google.com \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.