From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 E5F7228000B for ; Fri, 19 Dec 2025 17:32:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766165551; cv=none; b=rRh0fpm9N8md62bv8EdSuEuCFXRb5hJccvCuWfdtLeI7Sp9Gwfjo89B8V/Aq0V3zFuTGw94Jc9jqPN/aagpyd3+t3tV7/PWy2t2gFGsu4wQ6Gx2DZ0TN3DH335n75pDy1WTsJ2SiYt9Z1YjIdHEmqsHZkO+hJnAcpHspTus/Gnc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766165551; c=relaxed/simple; bh=SKR0y4ke7g6uJ3VfaXAV4HNn1trVq7fWIQgt9S4Hft8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gcdvutw0Ot8O9uXbofYdUMpA2y2ZUQ4ClEjYp1nJYsJNhrYOuI+1P8ObvZWarDNZzC08z9HoTUc6Jw5wHKpQvj+xLi/fuTV4YW1s4Lgfr7rAWpriKBoZVLY5XKbeU+6PSSgaccIDlBe+cZ462rygZIAnkMIIDM4OI8HgkIZGXXo= 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=fgkX3VhT; arc=none smtp.client-ip=209.85.222.177 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="fgkX3VhT" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-8b2d6df99c5so296607185a.1 for ; Fri, 19 Dec 2025 09:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1766165549; x=1766770349; 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=1hC/VXab9lpTCQATnomkfbW2pa0Vc9kadnS6vaPWuw8=; b=fgkX3VhTZy/Ty7vqFvfFyl85WVAwVSAYyNQCGbKSBtkeEfi4/S9aUVGtpS2il/BvsX 9dginh/2SgSNuWp1q+mnK9Y2IWXedcYnW1WEKuAVLOeMUNpPHUByLufNnWFsvoQDRLOX 8/+Kwkruvr7QSkBbRxL2LzCzwP3UzeZxpDd8YmUsJSS9Adjnu7jQp9igPB1DwVPbKiBt dEN3zIe5kLGnVj0VJJIAmWa9gMMDMuEY7zrAvJfBsxXidwHbbypUhXpSaUGHo6HSk+xr FGB5zKTvWG71ZGTgEL6gUMtOr25bchQUtOHfH0lEapzM45aW7oTBaFrKvQbLA99/Qdi8 uwjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766165549; x=1766770349; 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=1hC/VXab9lpTCQATnomkfbW2pa0Vc9kadnS6vaPWuw8=; b=UF79vr/ArAzq2bo1ui+RSPKB0z9YF0lBFtBFSjRtSrZ3+zlLzGDhgRKd6rOwQ55m+n sK7mnMLmfbFabxmc+vwB0oDYEUTng/gJq4NFXMI+SxrLdLhY+/yvfoPXrqzGgwqxTcMx QQN67bNX4RmkoaKOqwPT+Nx9gghmyi7igaE4akldhOEMWpmkKkod1Dd1qXqmc8B1zcpo 3DiovSZtZxNq0nEYCrpWN7r/YncKJKxpvqU/Cfx6Qo+OpbKV+98eeeCqPE8qFWB8UWGX 1vxOaFebpPS53YwdBQ5sM7mNIUSn16AAaQ69nJEuGnVwzKGmCEhSfIkx04jO72Uluh9g L9hw== X-Forwarded-Encrypted: i=1; AJvYcCVFaGqhkkfCqors6UTxvO4KvGmv9LE5MqdTbqSXgY69kVH2fQf90Qdsfcn+YgXTGd5Ufc2+NnlFpytgPhc=@vger.kernel.org X-Gm-Message-State: AOJu0Yzool/fMI9aKLzRhpIEKO7PvF2i4gwhsJBt8jUcn95QceIs7OAy VPv9foGdtmSsmPolVUYB1RwdqUipONNcOao29MOzxmpj7Tj7+xkPMe0MGBBumMOaCi4= X-Gm-Gg: AY/fxX6f2Xh5W0p9NvMQ3rmaMx1nqURSFFkyXDxI0Ui4b+7NR5Umx5yfLh2Q05QJvWD 5VvXzzVXv+rIkHyA0I7Fg6HKaAVqJUrfBUoatzBOzJit7n/vc1y/BpO15tusH/0T0L4PW8QtZAQ ouJf6NM1eJMpIQ8lAznKetMdpAO+yREqTASnDROMuNqcgT9/h70KCMorZzFQhWSUxDpTG384v7i 5/v4EwJSsPxAd1lcqEFCP/ehcZLxo7piRqi+EbKBsTCNBcd6ytrXY0qal6OtUgaBgpJ/pFQTXsB 7Qlk1DSXYi7paMh9COrAoR6s1eaHrBt3u7bZz4y+quOEeyI9dR3HDvSD2PzA0FlOayBsxzg53K1 4ELC596awO9cmQItCVNsDscoaTBSVqEikRZIbTNSJmHkykBJE97xjwLRcFkNCUXDPAdd29fhu7b NaBWGHo+wArk2kXRgVfLHZo2seuWgVOXk1QFn79VJeOZQ+NTDWhfeMd8VojUNwwBXoX5A= X-Google-Smtp-Source: AGHT+IGYAWh2sxLwizpTExt2w6pCX2ECxkldvqQUVe1MFbSK91RMxz7SwBO+heTsOJkJoalFRECn7g== X-Received: by 2002:a05:620a:c50:b0:8b2:3484:8e22 with SMTP id af79cd13be357-8bee5dcdd8cmr986687885a.0.1766165548739; Fri, 19 Dec 2025 09:32:28 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-47-55-120-4.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.120.4]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88d925f935asm23424216d6.0.2025.12.19.09.32.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Dec 2025 09:32:27 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vWeL5-00000001b6X-0xBQ; Fri, 19 Dec 2025 13:32:27 -0400 Date: Fri, 19 Dec 2025 13:32:27 -0400 From: Jason Gunthorpe To: Boris Brezillon Cc: Alice Ryhl , Miguel Ojeda , Will Deacon , Daniel Almeida , Robin Murphy , Boqun Feng , Gary Guo , =?utf-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Joerg Roedel , Lorenzo Stoakes , "Liam R. Howlett" , Asahi Lina , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, iommu@lists.linux.dev, linux-mm@kvack.org Subject: Re: [PATCH v4] io: add io_pgtable abstraction Message-ID: <20251219173227.GJ31492@ziepe.ca> References: <20251219-io-pgtable-v4-1-68aaa7a40380@google.com> <20251219140557.GH31492@ziepe.ca> <20251219161153.420d1c46@fedora> <20251219151434.GI31492@ziepe.ca> <20251219162734.46f3aa9d@fedora> 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: <20251219162734.46f3aa9d@fedora> On Fri, Dec 19, 2025 at 04:27:34PM +0100, Boris Brezillon wrote: > On Fri, 19 Dec 2025 11:14:34 -0400 > Jason Gunthorpe wrote: > > > On Fri, Dec 19, 2025 at 04:11:53PM +0100, Boris Brezillon wrote: > > > > > There's actually a confusion between TLB invalidation and L1/L2 cache > > > flush/invalidation. The things we can decide to flush/invalidate around > > > map/unmap ops are L1/L2 caches. The TLB invalidate, we don't have > > > direct control on: it happens as part of the LOCK+UNLOCK sequence, and > > > no matter what you execute (map or unmap), you have to surround it with > > > a LOCK/UNLOCK to provide support for atomic updates (GPU is blocked if > > > anything accesses the locked range while an update is on-going). > > > > That makes more sense, so these GPU drivers just flush the entire TLB > > every time they change it - built into the UNLOCK operation? > > I don't have implementation details, so I can't really tell what > happens internally. What's sure is that LOCK takes a range, so they > might be optimizing the TLB flush to only evict entries covered by this > range, dunno. So, I'd probably just simplify that comment: For the initial users of these rust bindings the GPU FW is managing the IOTLB and performs all required invalidations using a range. There is no need for it get ARM style invalidation instructions from the page table code. Jason