From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 ADAEC319871 for ; Tue, 5 May 2026 16:43:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777999410; cv=none; b=VHUHeo4ent/dBrGf9w8S7elJMla6vJidOtLfAZaTI6M2e+/3jf06nRRc5JHTJbQ5gG4ez/GyXKIQKD84QIloDZKBG2obvSn3N18aa/tMFWVmJ8euacWNUOSYyB26f1ZPvHBtp1YhPSnvCmpiPvPDYhxVdkEmUt06E45HAUHG2P0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777999410; c=relaxed/simple; bh=faS2CkT9BSZJpclVo/IT6hgfVCE3Khrz9KkbYaXxOUc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OaZvxd1OTfeGS6D56MQx8ccuoMoZnh1M6GKBUmI5z8KGSx8PCtGpwHxcM/gpx3nfFqqYNBmq77IP3y/Y6aWCEl0EsPEG1ExKdnpOC0Qcz3Nn1yiwAA9ZVy2Ebgo2t47Ai5l96+S2zmm0/eCCH/fJM2AfcIAbGZ6R9CGyRlswj9A= 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=aVgcmNIg; arc=none smtp.client-ip=209.85.128.50 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="aVgcmNIg" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-48d1c670255so2815e9.0 for ; Tue, 05 May 2026 09:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777999402; x=1778604202; 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=HIyq5XxnZOa3QCDQC431jNPLKmCFh6Pbs13KNByKE/o=; b=aVgcmNIgNb73QS9ROaRmXJ3Jhvnip3Qk8HppjLgf1MEGksf9rfDYG7CBJkDouN5+Fm ETd+eBDOmkVicwSNXlXQTcqKiBG9U8oi7fiQGokVPA5jSH4tV1ePKodM8Z0Ex61Zzqhx fcwS1SiG49g8Zc7OZCUckoljSN6qUbvzGAlkWYKs0L36vA3t6TXKB5P0N7TTUE2UVWt4 qF/V3/NsFjo5eJnBOAVeiurL0XxtDU+Dufy6M3ayMsik8XDdVsjcqUJLObTH6LEH9Obe 5lyBEtrbd3SPHweZ7C2G0YHD+WVDTVjIWl+lQVd4UqwI+fUHzXo8Cq4Z8TA6hCjB6Elj 9jhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777999402; x=1778604202; 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=HIyq5XxnZOa3QCDQC431jNPLKmCFh6Pbs13KNByKE/o=; b=pLcbz7CCb3/aLsHqYnlfXDEsTkrQwSy/UKpLa8EhYmdHCwBNeDySTGmQLmN7DSwqri Z/j7+CiyCqbN6l2G14yZV97M6tzXX3TmXNnllBx3wNdwqUNVimgSsmhvimjX85S3HNTo NpUVP1RRjH1sjx0rRjm/U/LKWm/OUfYXJrNBgCVRmujOIObY4RdT6nCf9AIYO+UBP7zU YvOFrejE9qR7YzsuZ5V9rLRekT3rheItkW/NCwycflJxmxUbBi16hTyYatexOVrJvDFW eTVNTTGntREQdMRwqYDLg6D0Zl88BHQO+qrDSTQFK6a0JnuhUnNS5DHd1uMdapnatRZw ckXw== X-Forwarded-Encrypted: i=1; AFNElJ+DT3md5sBNSmHAsKgPmgUKsorGmQj+WBBmOu26eN7qYz7yiRyoa6Zkm4THwylg5dUYTnjnic/PQSpnGBs=@vger.kernel.org X-Gm-Message-State: AOJu0YyThZYcXO/bnDv1B5eRKhayfSwBoJx2dIbGAZRkB1oZ6Ck7oo7Y FQewb24XHB7yST8MQ7PG8LX+l6fwlhvJbBbpw3ePHH+Jw2gSOCEuiiyItvAnDh8V/A== X-Gm-Gg: AeBDiet385KheTxWc8OE48bnvVQwfl+M4C6ibY/t4/HBdbjvJpsJTLgYDdABVV3yMAV CVwH0vIN1BwE7h0Vzz2XiqGtZGeMZcHmLQJVIuvjTBy3hSsbdFOD0Uri8gihFMZThAORUPB/Tcv h4Cgre0W8XrcUdSt7OJkZjVKTD/ZIEpMJD/Hvi0NPtV32qvK0U+0bzlqY82SpC+lpRZhou9FtjA 09xYrOxiZo38V+y1WCBZ1+pYaxu+xrCgRf+ZVI2A7d9ej65t1ntRVr0LDbxmenVz5K6G5/+fGM7 ZPss/a+CqUZbOFxleBuZVLdC9y1zxJFepVXmMZUaiCJYrfHzQm8aP4PX38/C/WzEetNb5RJeeYW gqSGMQMLxyVcVJ/uBKwsHMMw26HVY+KqWl9dMibtgPdSUUpOEBav5nQIR1sSBWojtmU7oyb9Frg slfMf8fsb3e/6+SBvb9lq8ZfL4Zq+s7yj4fGb7QPqfKEUPB2k9kNfCrBp2e3iWbEEK2cc+ElCS8 tfKZA== X-Received: by 2002:a05:600c:2214:b0:48a:6321:87f7 with SMTP id 5b1f17b1804b1-48d147423acmr907145e9.8.1777999402201; Tue, 05 May 2026 09:43:22 -0700 (PDT) Received: from google.com (8.181.38.34.bc.googleusercontent.com. [34.38.181.8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48d14e15ce9sm22679075e9.13.2026.05.05.09.43.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 09:43:21 -0700 (PDT) Date: Tue, 5 May 2026 16:43:13 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, iommu@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, maz@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, joro@8bytes.org, jean-philippe@linaro.org, mark.rutland@arm.com, qperret@google.com, tabba@google.com, vdonnefort@google.com, sebastianene@google.com, keirf@google.com Subject: Re: [PATCH v6 04/25] iommu/arm-smmu-v3: Move TLB range invalidation into common code Message-ID: References: <20260501111928.259252-1-smostafa@google.com> <20260501111928.259252-5-smostafa@google.com> <20260501124143.GB6912@ziepe.ca> 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 Tue, May 05, 2026 at 01:17:09PM -0300, Jason Gunthorpe wrote: > On Mon, May 04, 2026 at 12:15:17PM +0000, Mostafa Saleh wrote: > > > I am not sure if it’s worth it, the hypervisor is much simpler, there > > is a single page table, it’s locked (also identity mapped), it’s > > updated on VM boot/teardown only, we don’t even use iotlb_gather at > > the moment, although possible but I wanted to keep this series as > > simple as I can then we can add more features later. > > So this patch is the least intrusive change, as whatever the main SMMUv3 > > driver does, the range tlb invalidation logic is the same. > > But I am happy to experiment with that when posted. > > Okay, then maybe just always push a full invalidation? Like full address space invalidation? that will not be optimal and will affect every device on the system, why would we do that if we know the address? > > I didn't like seeing the range invalidation lifted out, especially how > ugly that will turn into after my next series. So, don't use range or > use the proper full gather flow seem like the right two options. > > I'm not so interested in minimal change, but maximum forward > maintainability. It is much easier to manage if you double compile > more of the driver exactly the same, and call functions in a fairly > normal way vs make special cases and special functions.. Let me try with your series, but the core range invalidation shouldn’t be changed often as it is tied to the hardware and wrapping it in a macro is reasonable (just like the CPU tlb invalidation) The last time this code was changed was in 2023. I am happy to use higher level functions to improve the driver maintainability, but I don’t see what is the problem at the moment. Thanks, Mostafa > > Jason