Received-SPF: pass (google.com: domain of linux-kernel+bounces-182372-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 17 May 2024 14:04:18 -0300
From: Jason Gunthorpe <jgg@nvidia.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org,
	alex.williamson@redhat.com, kevin.tian@intel.com,
	iommu@lists.linux.dev, pbonzini@redhat.com, seanjc@google.com,
	dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
	corbet@lwn.net, joro@8bytes.org, will@kernel.org,
	robin.murphy@arm.com, baolu.lu@linux.intel.com, yi.l.liu@intel.com
Subject: Re: [PATCH 5/5] iommufd: Flush CPU caches on DMA pages in
 non-coherent domains
Message-ID: <20240517170418.GA20229@nvidia.com>
References: <20240507061802.20184-1-yan.y.zhao@intel.com>
 <20240507062212.20535-1-yan.y.zhao@intel.com>
 <20240509141332.GP4650@nvidia.com>
 <Zj3UuHQe4XgdDmDs@yzhao56-desk.sh.intel.com>
 <20240510132928.GS4650@nvidia.com>
 <ZkHEsfaGAXuOFMkq@yzhao56-desk.sh.intel.com>
 <ZkN/F3dGKfGSdf/6@nvidia.com>
 <ZkRe/HeAIgscsYZw@yzhao56-desk.sh.intel.com>
 <ZkUeWAjHuvIhLcFH@nvidia.com>
 <ZkVwS8n7ARzKAbyW@yzhao56-desk.sh.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZkVwS8n7ARzKAbyW@yzhao56-desk.sh.intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?2ubUwMZMQRgJ4pQY7pUEhPsCeI7s/UD1TmmBtMEreXiwX7SmbijzmUU6E45W?=
 =?us-ascii?Q?j+dUKHYj9JQ0M3zXf2w9iZtXIuHtrYUHk/+3rauiJplUmox2koMozNmkj3Mj?=
 =?us-ascii?Q?vYQaDJq8a1jfzooYRsWWyozDK5zDj0B/uJ3FhIn6W168SlwB2tcJeV6SeKZk?=
 =?us-ascii?Q?RblJIDvC3dbtwMfIOOxPTXvHsfjZZbzoWAYtzk/olTspIBh90aIIhz06g0ez?=
 =?us-ascii?Q?h1QWaQc09dTY7DotdEIL4FJRVHVFrQXYJczkJ2teKxjJczxrLZ7M8rROJFlw?=
 =?us-ascii?Q?0GUjCqW/gaclIkiZ7uBfd3dYNJdjRj5yGTHNiCbNLcxFPphQyp6ErQGOXJtS?=
 =?us-ascii?Q?R4WFzr5iflhqXcfMnkFtRhSF52BZfYg4Nu3hhIUeKHAqS7nD6dcew42gBOx3?=
 =?us-ascii?Q?EZuZyRaT2xLupgH/Rw958oTQdqWbN1tT84Gx9Hpa89EnhGXhYzc/vTomhodM?=
 =?us-ascii?Q?0ri+4ZqO44DLZo/xY/JhM2sIbGw074Dco2dMFL11SIY8sDCBWAgDLkgQZbau?=
 =?us-ascii?Q?jMQNhfkJsUfB8GWnu4unuRnqrInFcWIrFjkn8dUrnN0NVipwhP9zjiPgwbJK?=
 =?us-ascii?Q?vyoR2xWidH2SDnqrRXHAfxI2Y6nyWzDD511OCKQelVE0cag2toZHkPJTpKLj?=
 =?us-ascii?Q?iP9Fiks8TuFcbRgEQRNC3Oaed6rmmcOACYs76WAjQyq1I6e/HNqAlbd/Hvaw?=
 =?us-ascii?Q?eiL/bOKzXZDm29A9kjpKpAy4t0TXkA/LbHuGCUlVfAvDeiDQdxT+VVnV3RMA?=
 =?us-ascii?Q?7I1p5YDP8DDsQXqmx++aVyhkzQGwn4JK15hKKAdP9PjPSOYAj9jXm7JEuaqp?=
 =?us-ascii?Q?gGOHoFkR8LqiIEXhFi95/ZLKTrPdbA4vhDDWJ0Fo+0h4PlA2IPIdKjjI9q1i?=
 =?us-ascii?Q?9BJujp/wWOSvZjAPfzeGNQcELGpjNMwCjocqZhKufWT2Cm5sn7qB7UUA7iKY?=
 =?us-ascii?Q?ItOyV6x3cMpDlY0tQ3IhYw+07mnmZp0fuxzk1mw2awsVPZ/Oov1AKs0HWTds?=
 =?us-ascii?Q?jKE18OiGTaXwuk5N52MmY7JlWXGGwxysXu6D3lAYKVbjX6bT+eq4Md85wiy3?=
 =?us-ascii?Q?heXJPpsmE0zk7qjQtzCwXciNtEDUxbjH1X+Xpqq94qdAWl0F3XYgWrdRRa4j?=
 =?us-ascii?Q?qKD7jb/acGOlso/JD/1a3cfTteZWcOo7E1+JnHIlPe+cA32BwnsLoS0huS3n?=
 =?us-ascii?Q?nfRHMx0B2Cpm5AK5P25H+j8VRFq7B41fEAVPPZk4KKHm26peScL+o7uqF+s+?=
 =?us-ascii?Q?RN60KKFK4YekJ5xJZr0eXcVvkfCHZr0QENauv4lcqzzWNRkBaCU30Dvm0jdk?=
 =?us-ascii?Q?qnoUQiRs4CchbuAjW0GeSzqrOeTW9zKO99x7GmMNCuezOUAzjl75Is2QW2bn?=
 =?us-ascii?Q?50461CZ4XqGxU+cX9ugmou8cQ/zI7oUfLYX8Zx5Ic1L1uzDwkH4HYFGtaC1Y?=
 =?us-ascii?Q?MDJzgPwGmnDtvSMQcpPyGQLFNNDAzRVfVCdyD7XOIZeA8mML6LWgXeLARdgV?=
 =?us-ascii?Q?AO+maCYJ6IAk3HzAX57YcInDfrd3dIt1Dqsmu55ggETfJrq6BQYWfBRDhN3s?=
 =?us-ascii?Q?orktO4A03KKovXlHVZvQi+qLTqqd+9vVrKEi1BE3?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 92312765-32f2-43cf-b1c2-08dc769364e8
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2024 17:04:20.6789
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bM8Qj6a0KOAkiALWH6WLeV6h9sRFgL743SHMVQp843jEhJszWi8KjGgQTpoX9Kws
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5824

On Thu, May 16, 2024 at 10:32:43AM +0800, Yan Zhao wrote:
> On Wed, May 15, 2024 at 05:43:04PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 15, 2024 at 03:06:36PM +0800, Yan Zhao wrote:
> > 
> > > > So it has to be calculated on closer to a page by page basis (really a
> > > > span by span basis) if flushing of that span is needed based on where
> > > > the pages came from. Only pages that came from a hwpt that is
> > > > non-coherent can skip the flushing.
> > > Is area by area basis also good?
> > > Isn't an area either not mapped to any domain or mapped into all domains?
> > 
> > Yes, this is what the span iterator turns into in the background, it
> > goes area by area to cover things.
> > 
> > > But, yes, considering the limited number of non-coherent domains, it appears
> > > more robust and clean to always flush for non-coherent domain in
> > > iopt_area_fill_domain().
> > > It eliminates the need to decide whether to retain the area flag during a split.
> > 
> > And flush for pin user pages, so you basically always flush because
> > you can't tell where the pages came from.
> As a summary, do you think it's good to flush in below way?
> 
> 1. in iopt_area_fill_domains(), flush before mapping a page into domains when
>    iopt->noncoherent_domain_cnt > 0, no matter where the page is from.
>    Record cache_flush_required in pages for unpin.
> 2. in iopt_area_fill_domain(), pass in hwpt to check domain non-coherency.
>    flush before mapping a page into a non-coherent domain, no matter where the
>    page is from.
>    Record cache_flush_required in pages for unpin.
> 3. in batch_unpin(), flush if pages->cache_flush_required before
>    unpin_user_pages.

It does not quite sound right, there should be no tracking in the
pages of this stuff.

If pfn_reader_fill_span() does batch_from_domain() and
the source domain's storage_domain is non-coherent then you can skip
the flush. This is not pedantically perfect in skipping all flushes, but
in practice it is probably good enough.

__iopt_area_unfill_domain() (and children) must flush after
iopt_area_unmap_domain_range() if the area's domain is
non-coherent. This is also not perfect, but probably good enough.

Doing better in both cases would require inspecting the areas under
the used span to see what is there. This is not so easy.

Jason