From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 36D4B38CFE5 for ; Tue, 5 May 2026 16:17:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777997837; cv=none; b=BiKWFbNR1f7EAJ9zCrsQzhME8QnZLKX80KD+n3HggYPxyWHxGifoYyx0zSm9pywTIT0778VTg1xBRf9eMHvbJhzvirGzBBHM3tGUF37/w3jJVe2VDqtAUuelwSGSOsH32VkiU14sS1k5U7fzTjdMJ+ryHrzn5D9cGA+Or18iFvI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777997837; c=relaxed/simple; bh=RNrRjG8F7y7vIp8q5Xm5bg/bZGzosl29uygoNMwlHPY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=I5GV8jeEzIwKLg7MyfcHL1CtsMdt5CJT4L/xqpkSRIFY9kUo+Zr21zrGT7wL/qd6Zze6hgQ3J/o+T27uJToWkIvVcWF6853Q/ojEor05F4k7mWZTjLNmpRX2+ZUXgpO4LtXIKVeISb1Pfr+5XnqyI/sC9+c/zUTaG1mVtUoOiCA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=VQbcrsDP; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="VQbcrsDP" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-48909558b3aso59613335e9.0 for ; Tue, 05 May 2026 09:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1777997832; x=1778602632; 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=RNrRjG8F7y7vIp8q5Xm5bg/bZGzosl29uygoNMwlHPY=; b=VQbcrsDPKmzlzgvnkcBuditfxno6pUp6ip5kSLHosDQ1TFNgArKUMyDHMoaU2f67Ua s9ZlAX/qlgjDDt8kXEiHWQKl3zYXxPJHDn0zh9qzN8pHdvXuxZjKSYN1jOhLQ6//3W/L 2njZg1rso2TIcjWdsVPrpUU/4xkEGl6l0Lwz+HjhO8lnsRqWD15ZQkEX3ijqMgYflxJ5 Ue1oDqDZAQKK+Ir7vEMz2RhFvUcAl2lWd73gaWd5MGem6ORqk5l0anIQvS/xhPhQx2NW G5B1llecFDMAKJWgDOO93zw0NwNmb4FanUfPKUg9Xq8/mmuWLfwtxqCK1zzzbvQ+yt65 KnsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777997832; x=1778602632; 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=RNrRjG8F7y7vIp8q5Xm5bg/bZGzosl29uygoNMwlHPY=; b=XNGGbxbtJ2IIq6Omqn3VpCx39JEXKyieq3AdzytovXjjgFPRYlLTriHKsJp76D38cD NH1IY6UuzZJbD1nAirwGsrF3kwaGcj3cgZIh9XhJf7rgRlK71/0kiTEhEIzpMbnovx8h xMp0B2gnV4gOkwQIgiOXeTjI/1brObmXw5HskcZLvOVznBV2ZewNIkLmqXRisQg7YPzb B728JHQWuVPi6iFFKsmZ2RcPaO4D+xXBq6ijseiCLHFi2xuq/EfH6qKP/uHeEkGFMIRt pJJIZu6xysKV3EmcEJxdAfwCDNwF01WIniwDnwY0ypZ2NrDv5O/PQae+MAtVGIKxePf/ M7aw== X-Forwarded-Encrypted: i=1; AFNElJ/V8pksuCv+HAx+M2vTh8EZUMqg3fyx/6XVPeDhondiUFwsxyPyawT8q3+jr7Q+vixcmD291Xmmac8gar8=@vger.kernel.org X-Gm-Message-State: AOJu0YyfMvMWcd8V5/xWNXOK7bJBLhcLFW0C5U+fh+58YDIKbulV6Yvn ypwEyK+By1UKYzgY+MqmTUGcTVqYWvkffvOZ696cXn2agy0xAuUBY3/RGtROkXU6jRM= X-Gm-Gg: AeBDiesz4ZknHMpRVCm6oKrIsIawwi8VqqBistdHHlkasd+nU9Z8hKWpm53NLZ7lZv1 ObfPDbrfSXT4ILrykOfvOMjFkRnlCF9pSxetIo/zoNTsb/05Jaxfa7FF2RMTbij8NzN4gzRDe3+ jja0OsmeXxzkPOdxSVlKF+4y7gbuf9cUc2dStmetDSIq88rBtPlPtL+Ka04iVTGH9I8N0rqlNDK V2FMMc2tUqVMPaJTKpw3N9CcQeKzRRdLCRhDlPyRThiko4S+wuNbMkXkK8gbwLE9seXnNhk2w6v 8qqycYx4bZQUi4May8a8hakeoypppEbOOUUcEfB/yJgEND6ixTo3k5KTISQS2nRhcY0B1qpEVp2 ia1SagMdXK+rTveB+x4i0DXdycr0cPNZ9qs/fECTBD4kIxPPOnuQsJUzVWF5EwzElzuS9Wt9vgP +mkkfXtQI= X-Received: by 2002:a05:600c:64c5:b0:48a:5574:3a48 with SMTP id 5b1f17b1804b1-48e51c6ade9mr1520075e9.16.1777997831520; Tue, 05 May 2026 09:17:11 -0700 (PDT) Received: from ziepe.ca ([213.147.98.98]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a82307f28sm692460135e9.13.2026.05.05.09.17.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2026 09:17:10 -0700 (PDT) Received: from jgg by jggl with local (Exim 4.95) (envelope-from ) id 1wKISL-000AN3-Vc; Tue, 05 May 2026 13:17:09 -0300 Date: Tue, 5 May 2026 13:17:09 -0300 From: Jason Gunthorpe To: Mostafa Saleh 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 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? 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.. Jason