From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (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 215E11DBB13 for ; Fri, 1 Aug 2025 16:57:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754067473; cv=none; b=LPuKvGAexyK84It6/LAKeeIu/X+29wXK9+plDgMmLEBdrv0mLBFWcqPTdp/SAe1KxBZxN4apuQw9OxZ6X3wyjha75qpSH9g8cIHOraR4yJYW1QLtAwAUTPy9h6rzRGv5F97ATHQBsabjR1kbbtfTCoz8Lc5lfKgfQfSd2BCGl6M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754067473; c=relaxed/simple; bh=vDejQUFTFKWHa1k801+hC0Yzdnwhqf+NoOVFx9dNlc8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B81HcedExkXICQNrNMraqEAS+3BLgmNUe87ykmDa9WfIDbu3R9iihDBZ5g0asM9ep/CgzqlUpuC57OKLjrreb1mNrSnkLqBfMLXZ4pjBKcekIldxTt8F1/IJH3I3vijx1DZmIM2BalbJ/ojJHBtDYtJ/CactwsLdYpuLy5AQgDg= 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=dJfM2wc3; arc=none smtp.client-ip=209.85.222.175 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="dJfM2wc3" Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-7e34493ecb4so113837585a.1 for ; Fri, 01 Aug 2025 09:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1754067471; x=1754672271; 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=PDG0NiUkE6aQQh2+3vtxR81GyiRPYX8OvGtHO76jA4Q=; b=dJfM2wc3j3H/mesSDcAy2ptGjlnL6BXpjsgyWzJDLDVFYdnsqt5oF97BRruv+vwT6a 31HxaCw6qlqOJa2BYhAPUHFJ4SGKc+ojIMm2eUiCVZQP4WjaqwlZhrbKpyGk/vmrumbg 9BWoqA6e4LwokCz9+z1VEnazea+g0p/XTPvpbw9HAxIR89DVJ0tO13hJxIWkYuJSFg7n xj+MP735juI0dVuhYEQwfU8ODF34Wn0nygN5D8gzlVXxuMrw7MUrs/0d4M2x9b5Rj2Rc F772guoSIihsoAWefuJGn/Il5QYW2hQyDqbrfk9xdBHB6bSJ69MB3qgOX7VSb7zl+U+G 41pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754067471; x=1754672271; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PDG0NiUkE6aQQh2+3vtxR81GyiRPYX8OvGtHO76jA4Q=; b=AFAZPHtrj3DOiB6ETgEFARNgLeCz9YOY5c/xsvh3B1t52FA26/tdS/W2+MUqMOLhJw wvX6tRCZ+1qv5dYLzq2HaLsZDepav/EOZIamkZUhw1O/uEjSkQZ2RZvaN3GUkZ/PA2QT 0PcYUSTOn4eZ9HT6u3Riml5uKwWi4b4MbHcd7oBeB6yGHo0WTNCv0iMQLflG45I+iVra 3eDfeQpHwP/EfyJ6Xv1IY4n+LRWzb/2FMyQ4qLatcy6OQPwfWaTW1r1Wl6iESHezop3T WINxZV9sIGt8z1ll4uYrKXT59Z0FJWMRPHBSd34TcSh4CpVHMhCpEZgnfYudM4A20e/d jNKA== X-Forwarded-Encrypted: i=1; AJvYcCWIn/gc+VuVosemLmga8ar9ij80PlsarjPVebWmzS5bkjcTm0ACjxM0kUHXGIx1optkEqpWAyiIToqlB0k=@vger.kernel.org X-Gm-Message-State: AOJu0YzgNtPZt6csSUHQok1xxeiS6i8U7RYCnIYthZesvTrA65efyGc5 wWivnqXafyJdBBnuB2Q4tyJiDh/kMmXzsT1G/1vCqTV2SidmetMlgc+N/xpmoRmMS9U= X-Gm-Gg: ASbGncuxjPMMpYO3SYby7RF6M+uzriMJiiFk1AtN3G81RDxInmY2GjgOixOfw/hZwK8 tgf1TaaW3w60VwtEyJJTvjWP6st3c/GuW5I5t7023VICAWvjevBLLrX6G/NvHbnzVl2HlUuSPQ9 XY1Nj3uuYWyd9S8ZpJ6Jr35+1uMUuxnfCtRmoEUZcKzpBL9y4+kzHTpnn39xIT6yx+pud/PAGgS GUH+5+45yQEiCOix7ZP7nFlF6mWg6ANpTsXR6rRCExKZP5H8Mzt5vA2Zm2Be4kQMPsG8kPAy7XD QKAwCKjSjz65WUh9skojOETIYdy0cNMlGnJghn3p5XHdwdFaXt/kl4fRfLYJwb/ffuQF+WiYoIV gm0pbIosD54DBOF6t53UXm4DL91W6QrZzeLWVrtIEBxYVyTOJruH+PLyf2cB3/800IBUo X-Google-Smtp-Source: AGHT+IERBfIl6+3LPr31vnFrHmPwk8v4BHZ0fVqJ0PrqlgFbKe+fN+UuB/UkeSinm2wl6jaqpYu7OQ== X-Received: by 2002:a05:620a:4093:b0:7e0:f7e3:7927 with SMTP id af79cd13be357-7e6962a98edmr81964885a.21.1754067470755; Fri, 01 Aug 2025 09:57:50 -0700 (PDT) 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-7e67f597e32sm234364185a.18.2025.08.01.09.57.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Aug 2025 09:57:50 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1uht4n-000000013IN-2zx7; Fri, 01 Aug 2025 13:57:49 -0300 Date: Fri, 1 Aug 2025 13:57:49 -0300 From: Jason Gunthorpe To: David Hildenbrand Cc: Alistair Popple , Matthew Wilcox , Yonatan Maman , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Andrew Morton , Leon Romanovsky , Lyude Paul , Danilo Krummrich , David Airlie , Simona Vetter , Ben Skeggs , Michael Guralnik , Or Har-Toov , Daisuke Matsuda , Shay Drory , linux-mm@kvack.org, linux-rdma@vger.kernel.org, dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, Gal Shalom Subject: Re: [PATCH v2 1/5] mm/hmm: HMM API to enable P2P DMA for device private pages Message-ID: <20250801165749.GF26511@ziepe.ca> References: <20250718144442.GG2206214@ziepe.ca> <7lvduvov3rvfsgixbkyyinnzz3plpp3szxam46ccgjmh6v5d7q@zoz4k723vs3d> <20250801164058.GD26511@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=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Aug 01, 2025 at 06:50:18PM +0200, David Hildenbrand wrote: > On 01.08.25 18:40, Jason Gunthorpe wrote: > > On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote: > > > > > The only issue would be if there were generic code paths that somehow have a > > > raw pfn obtained from neither a page-table walk or struct page. My assumption > > > (yet to be proven/tested) is that these paths don't exist. > > > > hmm does it, it encodes the device private into a pfn and expects the > > caller to do pfn to page. > > > > This isn't set in stone and could be changed.. > > > > But broadly, you'd want to entirely eliminate the ability to go from > > pfn to device private or from device private to pfn. > > > > Instead you'd want to work on some (space #, space index) tuple, maybe > > encoded in a pfn_t, but absolutely and typesafely distinct. Each > > driver gets its own 0 based space for device private information, the > > space is effectively the pgmap. > > > > And if you do this, maybe we don't need struct page (I mean the type!) > > backing device memory at all.... Which would be a very worthwhile > > project. > > > > Do we ever even use anything in the device private struct page? Do we > > refcount it? > > ref-counted and map-counted ... Hm, so it would turn into another struct page split up where we get ourselves a struct device_private and change all the places touching its refcount and mapcount to use the new type. If we could use some index scheme we could then divorce from struct page and strink the struct size sooner. Jason