From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 36E0634A784 for ; Tue, 10 Mar 2026 19:34:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773171249; cv=none; b=HTwZN+smrM9nW3ri+aN6nE1mUvXB4cZkSGHwA9VZHKZyrati4OvAuZRNjjWoRJXYw+7tqNKCCZH9fQCPh46mMep4SlOIObD3VnwPe+mARcjtoH40Q/Zke/2Pi/8E7i0X5JP0fDwJQB/+4fYErrkThTEA8qdRevWZQQz7m83lZ5s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773171249; c=relaxed/simple; bh=L12BluinyjkXyqIU2kYvAjopMSiSYL6fkPARo8pB4dk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GnKsVJury4LDVoliyZkhRywNMB1szMsfkVbtx3++ern8pH3EIV1mJSAr95ghl+/7NpE6rFrzaLDiW2a3DEXFdoe3IwUz5UPvKWbHQuJnUkiQcVQYIuXOfCaD9ymtmwzuAQQ8vJ740rSMia9bGLGVYWiTOt+mA2SsG3KomsApi88= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=tohDKC6b; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="tohDKC6b" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2ae49120e97so20575ad.0 for ; Tue, 10 Mar 2026 12:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773171247; x=1773776047; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uXGSMdyPLPak8eP7BVwmVxBskx1z5iRhXJhm2M1XFP4=; b=tohDKC6b89dw1Bfy1/X7h6TofUCl8GagcB0W6w7ahyuNvpa8n2kHZL1cMFDnTswnEt sWgZM03UQ8bQd2WQnaOOcHNttMfBJzEvbTo+PfROGLsLY4/9MqXyRxqPp055bu1WppRU QtJakuxscZ3QNSqZkp8DDWc8/Ii3hC5F2nD85ZqPBVHIfl8QOky+hXcw5pOGAfoikarf cuokH38P1zVTTomtSb8VL7Ur9I3T0GbFaSRmupgamt/pbEqVUWQZv56uHvGUD/sU3eR6 kNI1YcmhDNS26fSnc0QRbeyJLDPiSXXcxb9wVTdVrxusRerXUpDonWJEur88zpE/mBAn NiwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773171247; x=1773776047; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uXGSMdyPLPak8eP7BVwmVxBskx1z5iRhXJhm2M1XFP4=; b=HiAMGvfYS6kBRZz5A1PAMxNgzhn9v6sorDAVpxfxlpIO7ZEqJUElDynbzo8zXy44LN o0ColvI6HBiZAXwukZuAOcGkbR6sfVtqP+HaehZHh8Di+2gtyrcfBIqIrZD1jyRgQB27 pGf+CBsHcZtVLO8zgECeVTNOe+fxGjpCiWvZmZlm0g5e6n0EL6rIrR0AU2JCZDndJo+r ivVn9gwh74BS06gj8+XdRsN4fMVQtBsPy2epT+ATX9mkBsnL56bkI5v+gB8rMrMNVIXj pQqFy8/Ot++uw7H2ECZ4ACzXU857kelm/MITzgcxw5EVQnJeRUM0P6t8tK+2yrHsHirM t2JQ== X-Forwarded-Encrypted: i=1; AJvYcCU+wScxpaWxoNjNdrIAuA+tYT/+4f4Gb3rbEJKDXki1kQO7zWi6VeccNMbC4KAvNbJSQHMnyeP8ALVp778=@vger.kernel.org X-Gm-Message-State: AOJu0YxzXfCmtfTdhIRFIMB0zlJSbWwhrPkavK0wC2ssmTfq+F3Ij2Xy sc3C+SvykwB0nIFiEvQj5ipevxoI4oCcN5Bn+2Zp4CgZv0vYVBu+VGbdRxuoefYoag== X-Gm-Gg: ATEYQzz9Jl2Cfp5cXOrXE9hz/rWVDmxdzkWx1mZlLfaQYmtIjgRsIS7qzCLJJ+SgXNA ugZc/WK/H5j/4lXypi2THW3IW4uoRhQDhromj3whV9lWOGq2JT2xjVz/ZLVej8TkMr7zwmQx1h1 JS02nAMtuWBpc6eAtNbfEirvTKv1q5sVQhNBTPJ9hy4U/jGs9OXTJN3f5/aSP/RtxjkfVv6UNAW HiSKdrUYdGqTPbN5KZTOPiDnlW/Q+LWDEU34YNhqfTb/e0RK/fiM/TSHX8gONiTAYn8g7zA5zLi 2ndZ3qxCEmHWHf9kY4yX92KQLMes6XkIkGzJs5uRFc1ktG3vBbw61I2nDdtRzIGtCeM5js7FEMX fDxUIOoX/7lY50xNmY6lhK5AWXgnSLuJWvi1mGkfvdmmVau/TvIFcWfxPJk+QMbT8/72Ok2K8ph +S5jViXLjts+22NFVbhG5HCt1/0amL6k9ErBCMOL4BIEXm1UkJ9Jn0brrxSA== X-Received: by 2002:a17:902:f710:b0:2ae:4e8e:954e with SMTP id d9443c01a7336-2aeae7082d4mr4705ad.5.1773171247142; Tue, 10 Mar 2026 12:34:07 -0700 (PDT) Received: from google.com (10.129.124.34.bc.googleusercontent.com. [34.124.129.10]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae34d873sm382665ad.42.2026.03.10.12.34.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 12:34:06 -0700 (PDT) Date: Tue, 10 Mar 2026 19:34:00 +0000 From: Pranjal Shrivastava To: Jason Gunthorpe Cc: Robin Murphy , Nicolin Chen , will@kernel.org, joro@8bytes.org, bhelgaas@google.com, rafael@kernel.org, lenb@kernel.org, kees@kernel.org, baolu.lu@linux.intel.com, smostafa@google.com, Alexander.Grest@microsoft.com, kevin.tian@intel.com, miko.lenczewski@arm.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, vsethi@nvidia.com Subject: Re: [PATCH v1 2/2] iommu/arm-smmu-v3: Recover ATC invalidate timeouts Message-ID: References: <20260305235252.GC1651202@nvidia.com> <03461707-783e-403a-86fa-ae7a5107fa30@arm.com> <20260306155646.GI1651202@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260306155646.GI1651202@nvidia.com> On Fri, Mar 06, 2026 at 11:56:46AM -0400, Jason Gunthorpe wrote: > On Fri, Mar 06, 2026 at 03:24:20PM +0000, Robin Murphy wrote: > > On 2026-03-05 11:52 pm, Jason Gunthorpe wrote: > > > On Thu, Mar 05, 2026 at 01:06:21PM -0800, Nicolin Chen wrote: > > > > That sounds like the IOPF implementation. Maybe inventing another > > > > IOMMU_FAULT_ATC_TIMEOUT to reuse the existing infrastructure would > > > > make things cleaner. > > > > > > I think the routing is quite different, IOPF wants to route an event > > > the domain creator, here you want to route an event to the IOMMU core > > > then the PCIe RAS callbacks. > > > > > > IDK if there is much to be reused there, especially since IOPF > > > requires a memory allocation and ideally we should not be allocating > > > memory to resolve this critical error condition. > > > > Yeah, sorry, for a moment there I somehow forgot that we can expect to use > > ATS without PRI, so indeed tying this to IOPF wouldn't be appropriate. And > > given the general difficulty of trying to infer what went wrong and what to > > do from the CMDQ contents alone, I do like your idea of trying to return a > > new kind of sync failure back to arm_smmu_atc_inv_{master,domain}() so that > > we can take any defensive action from there, with all the information to > > hand. We'd just have to ensure that if a large set of ATCI commands needs to > > span multiple batches, every batch must contain its own sync (since if some > > other batch of unrelated commands could get interleaved in the middle and > > issue a sync that then fails due to someone else's ATC timeout, everything's > > likely to get confused and go wrong). > > Yeah, that all makes sense to me. > > The batching issue is scary, we definately can't allow an ATC > invalidation to be pushed without a SYNC that localizes any failure to > this specific thread, or we can't properly disambiguate the failures > anymore. > > My feeling is when the sync "fails", it can bubble up the error and we > can get back to the invalidation list processor which can then see it > failed to process an ATC batch and take an appropriate action. > +1 just saw this thread (replied something similar) > > The fiddly thing then is that we might also have to be prepared to "handle" > > CMD_SYNC timeout by manually checking for GERRORs, in case the whole > > invalidation is in the context of an dma_unmap within some other device's > > IRQ handler, which happens to be on the same CPU where the GERROR IRQ is now > > pending, but can't be taken until we can complete the inv and return out of > > the current IRQ :/ > > IIRC didn't the PM patches propose to add this anyhow? If this is regarding the runtime pm patches, I've tried to address the Gerror issue (pointed out by you in v4) in the v5 [1] Thanks, Praan [1] https://lore.kernel.org/all/20260126151157.3418145-9-praan@google.com/