From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 4089A41B35A for ; Wed, 13 May 2026 14:27:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778682479; cv=none; b=ZwcuYBIJ+4WRLzhY+Hqczs8k32wVco1JFa4JJK0lAYEWO6TgdSRYFJXU+9LAL/fWh4itwg0ZjAajEOHIZSE6zYUOEqLbxNsh6Q6qg4cX15LBAoBGXSb49iMl2zsfxXW//nH+jKZa+nBDs3Qv6bbjtiWidvL5gtYbisaVsltJaeY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778682479; c=relaxed/simple; bh=XJ3mfSG5bhBulx6TUSY6t5fiBkHC3+OsF05wOi9w0bM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o9Y/I9eH/JaKrv79Q+fof/p8b2zbNp2g/ZuNQAxc9N6h3zer1lGbC3VLMScijxRHomNliGrF+4LJNfxCoo6+Yoe9Q9K1aiQ5lD4zrqSJFhf+y5TkGXJw2ajFbg0OIJAqkX+NVqE8kW1l/UFefDiFVHYgPGJ0Tu5efwfmJCwEQsM= 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=SB1V9aIt; arc=none smtp.client-ip=209.85.214.180 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="SB1V9aIt" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2b46da8c48eso1525ad.1 for ; Wed, 13 May 2026 07:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778682476; x=1779287276; 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=3TnKwYV0Kzd1zXkaaqOGDYWO3WX2nNMrzmPg/2ozAlk=; b=SB1V9aIth3FGUtbCIAsItMyuNlbYe7Hjq5yih8HLiehfLj7Eqao+wq6QEbFY0y7jCd I+yiedw9+iap9KbiPwK2VMevlHcs0selF6/rYHWGhHT3fNnG+zxjkEYOq2tQ4DaL5SQ9 UjaurT+DHHVt0FlaJeC+nASMtX+Wajr0L3+fThh/Lx3U16bveTHaYTQRsgler+5Uh+Xh rGCSOY+cucIvvm2upssfP0TFE4+aGqmSRw8adfQIQPRb/7v+R48jW42UXlhtFvu4Anpw j13KniUnl1dTckobPQ4kWS8a6IodDePaey4bZhJva3pEnM08fNZ0ffXO68Cxjq393iAi SY1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778682476; x=1779287276; 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=3TnKwYV0Kzd1zXkaaqOGDYWO3WX2nNMrzmPg/2ozAlk=; b=YWA0vIlvx9CwLj+FP0H6wJ5DJopI5r3Y7/gW0RIYf/iY+8jYVeT5+/1PpCWWtjbKoa vaztfmpq7maO05uZlMhoyKv5E3AOag5y/nW13jDhsfkzEFkfwbgbt0wMm1MQdOAUeTA9 FOWYrk8gGHMiknaQJshoNjvq+H9mdKjK1bdLQjnpIxR0Bujm7+A3B2uRqKu+WvxRBxdR 86KgIzfCVJgsQi9Xh4sxtq8hOZnURuQdyVZCAbO4xznT89eXMdaHEtJzAtf3MoBdqqUE DEzCcypbCa44zZoBS9U6z7MXSteCF+BXs/7EyohJgGaLB8yL/z0b5DpHPYkPt0xXs612 1lqQ== X-Forwarded-Encrypted: i=1; AFNElJ/d5yxSORo4Edgjh5uD0FHAWmq+yFR0Cchzo8npavos5/2whgnJdoliwLtBFJkqvR9sO7ZbUWDq9toUgEk=@vger.kernel.org X-Gm-Message-State: AOJu0Yw7m13hm5ChubEewUpUJs579d8qcP+tPX+vAkr/GYFm9TRJUTIv c2ZN46OOn8JZMtvrz6R2O1fTEzrrEJ00Fb7TzKnFLWrc0LQZP/y8tlitSH35goGkN3coGAS2a/P mNL/Oiw== X-Gm-Gg: Acq92OHwNOvaAbZRafwhCr7XBBUxKCW/IsMSzji8a78clEt0cIYeQpvlvrU1dzuDFWy GuCSlC+EVtP35sJSGjrMUTLBE5LcdkxeUJl//JemtqcfvV2GaMWMPE57ALAxadSFGBqQc93C3J0 ZfUkpsLLWJX1FyCrND0TPwf/ik29EO/3CmmKqpjdIS8higQcQDREym5Ae6lGtxYhcOYqZbNxsng 9w1u+hMMdMFaBRh/AGfodFgKxcMetoGqQ8zXFCkhlmLsDf6WjWJD4/2SxSfVdR0IvRLGwew6VT4 QCSxKhfT0TEojNkDJYmNI4e221MX1pf8fU0KUQ/CMuifOFPB17kANG3Dkfe+qJH4XEaBiUEB1jj ds1b2AmNgW3yKFGb+371yzc2hgQ4jO7sebn2zbT1/s6cL5kWmaInSkJ2br0zBU6xv10fl58cIvX zfwoCpxwYFqFHnPC4j+hTZEfJuc2Pbjf6U8GVsPHGeXg263jMVavR/7Oteo5JX3CAPVjsT X-Received: by 2002:a17:903:2154:b0:2b8:e82d:ff7c with SMTP id d9443c01a7336-2bd2c0f12bemr1729045ad.9.1778682475851; Wed, 13 May 2026 07:27:55 -0700 (PDT) Received: from google.com (44.234.124.34.bc.googleusercontent.com. [34.124.234.44]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-368edfa2fb1sm3416572a91.17.2026.05.13.07.27.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 07:27:55 -0700 (PDT) Date: Wed, 13 May 2026 14:27:48 +0000 From: Pranjal Shrivastava To: Will Deacon Cc: Nicolin Chen , Robin Murphy , Jason Gunthorpe , Joerg Roedel , Jean-Philippe Brucker , Catalin Marinas , =?utf-8?Q?Miko=C5=82aj?= Lenczewski , linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits Message-ID: References: <20260503135413.1108138-1-nicolinc@nvidia.com> <20260508123550.GB9254@nvidia.com> <4e129891-2f52-4bac-8e33-1fdde42fd29a@arm.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: On Wed, May 13, 2026 at 12:42:47PM +0100, Will Deacon wrote: > On Mon, May 11, 2026 at 01:22:23PM +0000, Pranjal Shrivastava wrote: > > On Sat, May 09, 2026 at 12:56:57AM -0700, Nicolin Chen wrote: > > > On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote: > > > > On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote: > > > > > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU > > > > > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates, > > > > > Since the fault handlers are already expecting HW-triggered updates? > > > > > > > > > > Which means our check would be something like: > > > > > > > > > > if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) { > > > > > if (smmu->features & FEAT_HA) > > > > > ... > > > > > } > > > > > > > > > > instead of cpu_has_hw_af()? > > > > > > > > Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences > > > > mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte), > > > > and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any > > > > CPU doesn't support HAFDBS, so perhaps you were right the first time :) > > > > > > IIUIC, v2 should be: > > > > > > + /* > > > + * Enable Hardware Access and Dirty updates (DBM) if supported by > > > + * both the SMMU and the CPU. It is unsafe to enable SMMU's HTTU, > > > + * if the CPU does not support it as it bypasses mm page aging. > > > + */ > > > + if (cpu_has_hw_af()) { > > > > Ack, yes. IMO, this is the correct system-wide gate. > > Hmm, I'm not so sure :/ > > cpu_has_hw_af() doesn't take into account CPUs with broken DBM and, in > fact, ID_AA64MMFR1_EL1.HAFDBS allows support for AF to be advertised > without support for DBM. > > Having said that, I don't understand why we need to care about the CPU > support. The comment above states: > > "It is unsafe to enable SMMU's HTTU, if the CPU does not support it as > it bypasses mm page aging." > > but I don't understand what that "bypassing" means. vmscan should still > pick up the correct state from the page-table, so what's the problem? I agree that for the Access Flag (AF), vmscan would eventually see the bit in the table. However, I’m concerned about Hardware Dirty (HD/DBM). I know the vmscan might eventually get to it.. but here's my worry: IIUC, in arm64 the dirty state of a page is tracked through a specific protocol using the PTE_RDONLY and PTE_WRITE (DBM) bits. A shared writable page is initially mapped with both bits set (_PAGE_SHARED [1]) It also seems to be documented in arch/arm64/include/asm/pgtable.h [2]: /* * PTE bits configuration in the presence of hardware Dirty Bit Management * (PTE_WRITE == PTE_DBM): * * Dirty Writable | PTE_RDONLY PTE_WRITE PTE_DIRTY (sw) * 0 0 | 1 0 0 * 0 1 | 1 1 0 * 1 0 | 1 0 1 * 1 1 | 0 1 x * * When hardware DBM is not present, the software PTE_DIRTY bit is updated via * the page fault mechanism. Checking the dirty status of a pte becomes: * * PTE_DIRTY || (PTE_WRITE && !PTE_RDONLY) */ Thus, if the CPU does not support/enable Hardware Dirty management (TCR_EL1.HD == 0), it is forced to trigger a Permission Fault on the 1st write because PTE_RDONLY is 1. The fault allows the kernel to call folio_mark_dirty() [3] If we enable SMMU HD independently in the Context Descriptor, the SMMU will see a write and silently clear PTE_RDONLY in the hardware table. When the CPU later accesses the page, it sees PTE_RDONLY == 0 and proceeds without ever faulting. Now, if we're work on an SVA page, with only SMMU supporting HTTU. A DMA writes to the page and the process (CPU) calls fsync(). IIUC, it performs a lookup in the Page Cache specifically for folios tagged as DIRTY. Since, vmscan didn't run yet, this could potentally drop the writes.. Thanks, Praan [1] https://elixir.bootlin.com/linux/v7.1-rc3/source/arch/arm64/include/asm/pgtable-prot.h#L61 [2] https://elixir.bootlin.com/linux/v7.1-rc3/source/arch/arm64/include/asm/pgtable.h#L390 [3] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/memory.c#L3698