From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (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 8E8A51A5B90 for ; Wed, 22 Apr 2026 15:44:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776872682; cv=none; b=FGif/petsmIyaJT95GTZYA9mPkBVOL+SRupqKTqdldKKTzpnt0yF6nqI6VRtmcc/JXlwXyYNdgaS7osqxCxFX8psgpPCN9WR3db5HLsS9bsfToJlbR0MeFzmWUVIg/tpJxYkV8X5ofLGGgZJpNfIwDlBSzuEpvwJ3bjV52oAVww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776872682; c=relaxed/simple; bh=avnk4GU77eJdWBqpzi1y776H5v2VdhpFnM8ByuUntY4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eiQ7705QnRkjxbtHjYdzi4NM7lwSiMaLfQxHyHiHibLJdm1H5xCABkYb4IS7AvTYe8XRemgaPkl4srVfCz+i2KTy91Zl2YHA+hTqtGSOUqfK8rJM/JX+JgQ/cOUjXqJm8lExsNas1SbtMHD21i4/14iu6mCz7o/4/8hwGh64Dto= 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=WPUPvgoR; arc=none smtp.client-ip=209.85.214.170 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="WPUPvgoR" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2b46da8c48eso9945ad.1 for ; Wed, 22 Apr 2026 08:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776872681; x=1777477481; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=3/bQL7TanDi+LGxlRj56HG2qI4sxsGUbPbeeZiNiay8=; b=WPUPvgoRB/vcdgiH4jYMNFDGSmnYazySK4tcSV4pWseeXauRDLQ89LwRa+pqolsX6x m7oXoQ/CK/BGom7AzG2kP/yss8W0ztHiiSgqNr2/l6NgdhSPoZJ96Tatnflm3sFjNpVe 8tvS4Z2m9xQCKFYaB3JbSbOWNpV9SsAwVNVyGQNaGBds+76lQzc58U+VHDIREr9Mw/ay XCgsJt6S6J5aUG2qxswKVELv8mB3KUgySFceCP3K1sNvdGiuc8p5hQzVLfQVhnslqpzU /t+e0A3vznNnQE6G/c9DSNqhYpfOhNqTzMZCWPyJUAIe8Bud3vg9abkFq1Q25HkLUSUH bjSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776872681; x=1777477481; h=in-reply-to:content-transfer-encoding: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=3/bQL7TanDi+LGxlRj56HG2qI4sxsGUbPbeeZiNiay8=; b=GvkOoYbb+uV56yDhvcyNg8dJomfnyJJiJWxmv60QYL9W3ba0D59JSXPfvUXOcqAd81 4ugiBWwmdsYyR4JcxK5NAspy9QQq013xbm9hbP7Jes1UvFBzvjsDzbJPlQS7Y/omtb6/ eMWjWDypahAF5tDvAaAOsVbvGi63nA/8D4lHU+35P9QVcVDI42g9ssNFt149bzYKjLec GWnYedeJvgK5fr5k/PgJ+z/477xxn8gEsJs0JG/NXZ3krd0SfNyy0Ecp7UlNIsUy6dvC IutnesKwhbkFx591PekftO6UB7kazdyUQc3b/KikQibOv/bZL8qoGej+HxlgHEm5d0MZ 3ibg== X-Forwarded-Encrypted: i=1; AFNElJ+Nhe0AZzlgozqxNVFCbSOAukj1rHyi293EbrHk72f5Bq8HV5gyfGxgS4BoJIcsp8ccLgYq117p7wO2X4Q=@vger.kernel.org X-Gm-Message-State: AOJu0YxBtSePrJBjZ04DJZa9rnxdKGOnbS4IDDZIrATsm+TvSlbMSD/0 RRq/1zJoaCF4BRkpj2vUck+stH5ulDAWhvVI/N671Qo6/vNArrSJrZ+23kAIJBeEmA== X-Gm-Gg: AeBDietYYNTqnmtRMmt6E1YzUZm6S1ScePW7HaoWuKP6JI0peZCMvaD043LyDhYAEiY eerXR1rm6HGPprXcDkILYKKSDpwBcZ/nw/vfICBt+TTM/yVklf/FpMCgSXPMdg7ytcAbuTPemQl MNjWU3PrQzKuEKoxgLyDLDkZYLizjTyx6VCTASeNkQBrC/L1fi/0XdFPAUaLYMEJ1FYVcXaxo4j zLwjVANXuNufdauvCgG9PwQXuy9w6Qa/T+98kpehSTI21y7GWNniUq71O7Qwwxr6WlgAQN7SIJ+ CGnrptiTip0HxM59Rgo3qlkBVM+qdQhOW/15RdBgNIquHTna4tWlMzswL4zWVNoyWkd3RxQ8itw Iu2/kq92YXCddr7sXA7itkPWUX7hasj3vzEYAc0Ys4noJoqCJTGYf8Hj+nsdWa1i+K5HMgoTnZ2 NUPzdx0GmC7peWcEk+UVMBdIh4r7PmldVIVaFPr106GdajsxNS5W0Q6ia+AJUa/3vrgE5tPw2Ih eKTTK4= X-Received: by 2002:a17:903:2f10:b0:2ae:4e8e:954e with SMTP id d9443c01a7336-2b603f3d6demr6173345ad.5.1776872680351; Wed, 22 Apr 2026 08:44:40 -0700 (PDT) Received: from google.com (174.188.87.34.bc.googleusercontent.com. [34.87.188.174]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b60003ffd7sm152803975ad.80.2026.04.22.08.44.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2026 08:44:39 -0700 (PDT) Date: Wed, 22 Apr 2026 15:44:33 +0000 From: Pranjal Shrivastava To: Evangelos Petrongonas Cc: Jason Gunthorpe , Will Deacon , Robin Murphy , Joerg Roedel , Nicolin Chen , Lu Baolu , linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, nh-open-source@amazon.com, Zeev Zilberman Subject: Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation Message-ID: References: <20260420123221.20801-1-epetron@amazon.de> <20260420124032.GO2577880@ziepe.ca> <20260422064431.GA49867@dev-dsk-epetron-1c-1d4d9719.eu-west-1.amazon.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260422064431.GA49867@dev-dsk-epetron-1c-1d4d9719.eu-west-1.amazon.com> On Wed, Apr 22, 2026 at 06:44:31AM +0000, Evangelos Petrongonas wrote: > On Mon, Apr 20, 2026 at 09:40:32AM -0300 Jason Gunthorpe wrote: > > On Mon, Apr 20, 2026 at 12:32:01PM +0000, Evangelos Petrongonas wrote: > > > When the hardware advertises both Stage 1 and Stage 2 translation, the > > > driver prefers Stage 1 for DMA domain allocation and only falls back to > > > Stage 2 if Stage 1 is not supported. > > > > > > Some configurations may want to force Stage 2 translation even when the > > > hardware supports Stage 1. > > > > Why? You really need to explain why for a patch like this. > > > > If there really is some HW issue I think it is more appropriate to get > > an IORT flag or IDR detection that the HW has a problem. > > It's not a hardware bug there's no IORT or IDR bit that would make sense > here. > > The motivation is live update of the hypervisor: we want to kexec into a > new kernel while keeping DMA from passthrough devices flowing, which > means the SMMU's translation state has to survive the handover. The Live > Update Orchestrator work [1] and the in-progress  "iommu: Add live > update state preservation" series [2] are building exactly this plumbing > on top of KHO; [2]'s cover letter calls out Arm SMMUv3 support as future > work, and an earlier RFC from Amazon [3] sketched the same idea for > iommufd. > > For this use case, Stage 2 is materially easier to persist than Stage 1, > for structural rather than performance reasons: An S2 STE carries the > whole translation configuration inline. To hand over an S2 domain, the > pre-kexec kernel only needs to preserve the stream table pages and the > S2 pgtable pages. An S1 STE points at a Context Descriptor table and as > a result Persisting S1 therefore requires preserving the CD table pages > too, and because the CD is keyed by ASID coordinating ASID identity > across the handover. > > In the long term the plan should be to persist both stages. > However, until a patch series that properly introduces SMMU support for > is developed/posted we would like to experiment with S1+S2-capable > hardware with an easier to implement handover machinery, that relies on > S2 translations. > Hi Evangelos, We (Google) currently have a series in the works specifically for arm-smmu-v3 state preservation. Our plan is to post it in phases (S2 preservation first then the S1 + CD series) once the iommu: liveupdate persistence series has stabilized. Since the iommu core liveupdate framework itself is still in flux, it’s a bit premature to accept/merge this patch before both the series. Furthermore, it must be noted that even if the iommu liveupdate series is merged, until the framework is fully integrated with the SMMU driver, liveupdate shall remain essentially non-functional or 'broken' for drivers that haven't yet implemented the necessary support hooks. We’d prefer to wait until the core infrastructure is solid so we can ensure the SMMUv3 implementation aligns perfectly with the final requirements of the iommu liveupdate persistence series. That said, we don't mind posting our arm-smmu-v3 series with S2-only preservation early as an early RFC if that helps align on the design and implementation details. Thanks, Praan > [1] https://lwn.net/Articles/1021442/ — Live Update Orchestrator > [2] https://lore.kernel.org/all/20260203220948.2176157-1-skhawaja@google.com/ — > [PATCH 00/14] iommu: Add live update state preservation > [3] https://lore.kernel.org/all/20240916113102.710522-1-jgowans@amazon.com/ — [RFC > PATCH 00/13] Support iommu(fd) persistence for live update > > > Jason > > Kind Regards, > Evangelos > > > > Amazon Web Services Development Center Germany GmbH > Tamara-Danz-Str. 13 > 10243 Berlin > Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger > Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B > Sitz: Berlin > Ust-ID: DE 365 538 597