From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (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 C21D3208D0 for ; Fri, 19 Dec 2025 14:06:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766153162; cv=none; b=qd+9ubK3G7Rd5WOYruGGMXAiOyLDWso/xUOb4gilheEEMBBZy+ZX2C+YshPDtc88DOtptRDgommhf1p24XoGgRnKgvznu2wwqjKY/1Ydn8wKwQnZ7UE+pRcVnyB5Uuc77HK7+I5JBt9sO1pxnXNGsSe2PiTZQ0uzfxu/jqJopuA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766153162; c=relaxed/simple; bh=nIsNPow5kM9UVujhZhsZ0wdNvrec7uwwcDAP2NNAzuk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KthLgSjHq4dE9segodnHCKddaiXoBavYiJS3JwMasPvjBff3n4iHMkaSusgvY9Tf0+9eFDZwAj+++5e2icrDn5p6QWg5TdGfSHY7jMkSRw9sUgL7XoozV/a1tBtGYuoIM2VYsn+9m0wsdBb+xRbL3gVsRYHhqkrdZ2q8yvzM1qI= 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=ggenF/6P; arc=none smtp.client-ip=209.85.219.43 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="ggenF/6P" Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-8887f43b224so24534876d6.1 for ; Fri, 19 Dec 2025 06:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1766153160; x=1766757960; 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=zZMm+69u9x+z8ibStDNPIaAJod8bPs48RdpWzI/bCtw=; b=ggenF/6PSAYUuFaSNwkOwq9giHS1PXiTe3eVN5fQMURUat0Ao11jibY8qgNXZmSg57 AU9zdcaQVqX4X1QpkkU8vqJClJR9Z59lzYiH8LCnTMOBtFH/Ik0oBQhxEaso1hYVG0Ua HfrbWWH5vQgGt5rXnp3412B6GHsBFu1Zfr4TKyAzfEQK7aaTlLvPbA3ouSJxZ6+856dg OGYI4iWdn+Y3l8e3esQ8ReqnCGShEYy5W6NaeVB1LEhsym1RJjDwIxxazqDCMAIna+Br kETh05AA3hpOX6uv0SYzIY6CAPyuKeljCvDIFtCENZDQY2sOSj5EWzuhBkDr+3F3Uhhs CXug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766153160; x=1766757960; 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=zZMm+69u9x+z8ibStDNPIaAJod8bPs48RdpWzI/bCtw=; b=QcfkwbPrJ/Uij626HYdTqdqYRuBvn5lBTL4ulcmnUEVwFh3gwrGHYSIe5q8HJzeMsu YJkntp0TeUWrVLdDH8qleRNyGzY/vQHTgEwCFgR5MdAIjsM2XnESAUZrZcYvlf3EJScN SSR7HVlFCuSAjsPX5ZQcB1aE1Qma2B4YEVJA385WroVjD8uT1iLgLCBQJScCqMwtrZB6 Km5LrrW9qpFAZ5EV0WP5B3Y6CYG502mRwEBMme5qLjuqkINXpnG7p7XggEs0/gfoyH41 6Hv1eQ9mOACszscdG2ktiOwZ9FQ/pOiv5hjr1pzB0WMyrH0dQe237trhjm+cLpG4iNxO MN4A== X-Forwarded-Encrypted: i=1; AJvYcCWQ9n2wXigM/OlaTvjkTW4FCGV6OwN+sBEbH/31vDopQHBseUUI11JGAMiYueVSul3VHVEdkYNs5NmPUMo=@vger.kernel.org X-Gm-Message-State: AOJu0YydxlEMuZYpUxwGtWV+h7Xw/SZ2qApe/W8Gk1LfNP8fKZoGRHZ4 9d7ynd+NXQTFx83IDTaHwUypKU5A8Fi1YwU6ZrlX8cm3qgZ8WgLzDBHSk+L4x/ePeOk= X-Gm-Gg: AY/fxX607GLrgblIBeCrzQABm1V/8yjMqIGt3ZaSArAyeBJrknX+fh5gHxdMDhr6Sa0 2ZOYlxBf+XCgm5f1IJ7Vb2eBkVdnWJlwSMCI1lP0CTthLgfE60KS8TSr9J89rRHx1gerwqF0B04 y+DjPlZjwwkm2tGjw6VuYiUuRDDFBWy3XJKh8fwDMDmYQgnNpmKocVyLYOURL6hr68GZW2uh73n y+ggAWDiRCtfG8W5aFVwXBMGDynTZ6RofrlGo3wQXGbHF7ZoA0Nxwr/nkWGQ/ljHT2lOY+UEIvY PA/ir2HAv+vS1f0APtm1w3QuHNrWfVMvZ7kGCLkbn/VvveDuC0tp9ZyOABgLhBqy9AAtRcsEuMw QliYkAtwlAdXWlFkWO0YWneMOd70FjT3yKSa1hnNMWkizBpSQitHAp0M2hhcZ1E33W/KYKU6iMN 4za3JgJXsK89LHWnhRQsYYuWBXmFJjwdSmJVVCcujJBV8EdIw0Zizoyx6X X-Google-Smtp-Source: AGHT+IFvQBh34jY1BRicAO6irDa1zAgb1lDbuHzEzV01DhrEsnJRDHmMIYj0wyL099ZnzNEOzHLyuQ== X-Received: by 2002:a05:6214:4ec1:b0:88a:3b1d:2f70 with SMTP id 6a1803df08f44-88d8166a292mr48660746d6.10.1766153159564; Fri, 19 Dec 2025 06:05:59 -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 af79cd13be357-8c0971ee182sm184273485a.33.2025.12.19.06.05.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Dec 2025 06:05:58 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vWb7F-00000001Y07-2SxB; Fri, 19 Dec 2025 10:05:57 -0400 Date: Fri, 19 Dec 2025 10:05:57 -0400 From: Jason Gunthorpe To: Alice Ryhl Cc: Miguel Ojeda , Will Deacon , Daniel Almeida , Boris Brezillon , 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: <20251219140557.GH31492@ziepe.ca> References: <20251219-io-pgtable-v4-1-68aaa7a40380@google.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=us-ascii Content-Disposition: inline In-Reply-To: <20251219-io-pgtable-v4-1-68aaa7a40380@google.com> On Fri, Dec 19, 2025 at 10:50:52AM +0000, Alice Ryhl wrote: > +// For now, we do not provide the ability to flush the TLB via the built-in callback mechanism. > +// Instead, the `map_pages` function requires the caller to explicitly flush the TLB before the > +// pgtable is used to access the newly created range. > +// > +// This is done because the initial user of this abstraction may perform many calls to `map_pages` > +// in a single batched operation, and wishes to only flush the TLB once after performing the entire > +// batch of mappings. These callbacks would flush too often for that use-case. > +// > +// Support for flushing the TLB in these callbacks may be added in the future. > +static NOOP_FLUSH_OPS: bindings::iommu_flush_ops = bindings::iommu_flush_ops { > + tlb_flush_all: Some(rust_tlb_flush_all_noop), > + tlb_flush_walk: Some(rust_tlb_flush_walk_noop), > + tlb_add_page: None, > +}; This comment seems quite off.. Usually you don't flush on map, you flush on unmap. The TLB should be empty upon mapping and not need flushing - except for the rarer special cases of clearing the walk cache which cannot be detected any other way than using these callbacks. Doing a big flush on map to deal with the walk cache would be worse than implementing these callbacks. The flush on unmap, at least for ARM style invalidations, needs these callbacks because they provide required information. If the actual HW does not use an ARM style invalidation system then this page table code is not optimal for it. Jason