Received-SPF: pass (google.com: domain of linux-kernel+bounces-179541-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 15 May 2024 15:06:36 +0800
From: Yan Zhao <yan.y.zhao@intel.com>
To: Jason Gunthorpe <jgg@nvidia.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: <ZkRe/HeAIgscsYZw@yzhao56-desk.sh.intel.com>
Reply-To: Yan Zhao <yan.y.zhao@intel.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>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZkN/F3dGKfGSdf/6@nvidia.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xalw6sX0ElzjVyaNmMIYIS+htcbqDxOCX6hOOji91YLA1mNiAZmneTDc2tkf?=
 =?us-ascii?Q?dEkQlpgJ+lrRbokkP9VL1LMj1i/C53I95PSdzNbT0IH2cgojJhzSa/TR/jwX?=
 =?us-ascii?Q?5PkyUC0qBRQ/YMzo+FE2zs0Y9OsQaqE+/P/z4bkQSHGnIoP4ckPyDg7AYpby?=
 =?us-ascii?Q?VqsdV40qFTa3om7mQCE3h7RAW6cnTxbW7JuItmSl2gL+1ExYLrZdqMpOS5Fb?=
 =?us-ascii?Q?JhoOvwvs6OgNzfiL/Y1rkZ/GLwtQ1LfrsPlPo/5mkZdU1OY9qBHL/wPYWjtT?=
 =?us-ascii?Q?CvrQidQVx5bg7EYO6kBLngPHPQfEvk+PoEVeVN5nfalzS8Bw7XLF4B2Ytrkc?=
 =?us-ascii?Q?mTx6MSWd2mjqyCSZ0wNlruZMB47lcrhBiwNo/id/g04jPkndcGrasfjZ/qWY?=
 =?us-ascii?Q?DmO4RN3HAacibGSXKqe2PdxZJF3YuZekByRAdU0DJ64h3JolXD+Xe/bUXi2z?=
 =?us-ascii?Q?oIoOZLPoUnnm+OPusq6oFZumf5/uG8M9rxTVJAkTDepY7J9ApqjMfAFmMG9z?=
 =?us-ascii?Q?uHd5OxIAp2nZUHHyaY3lguCJi1FcXA7M30Zo9kvRG4HKBX2UKl8aHrIguG/K?=
 =?us-ascii?Q?H4xrxzKKsMzHVu4i+E+a1ewXcNoCArOOrRb026PNpG/QBAeR9BAvua6m5cKY?=
 =?us-ascii?Q?JMvcM6tnz9aaeiozcClzPcmKHBzw4mxq799FmcCS3RnvFQ1DmmPkPBh55kcd?=
 =?us-ascii?Q?/DcarXwP9xH4EblIDnheNp+OXRav/uAp2Ji9SqE1nhZoJTOPlyBlc0qMLJVz?=
 =?us-ascii?Q?21w4GS0pCyOloyf+X5zqgGpu+bve4wF7S9UgXtujlcmCXieF4hTx0pliF8Ea?=
 =?us-ascii?Q?W/oxBE2m82lPUhFSfxzD9JtsHYUi73Afs8MiVvwLCr7klKvxVC7z+ApLEKEJ?=
 =?us-ascii?Q?cq6YmDsdw8eitR2TNvFkoGeV0Hn8pYaPSR+8zLlvkgfo+p1d+3nRcUum58lQ?=
 =?us-ascii?Q?jwgLrIjehlQSwXz8EeWTQLQ58zlXpf+SOXaWEQM/gLaVbpWr3e82Ue5Qabcg?=
 =?us-ascii?Q?C/ah7S0AZSzDW9orXkB5/kEp9BO81tivnI7kQmI0Wk25+166DIzlC8+ZecZJ?=
 =?us-ascii?Q?nbns9iXohMC+PFbhUvEKN2QUmol6o9kywwDzdmcBGI5RbuXV9UFbdnNnxJ5+?=
 =?us-ascii?Q?W3B4BXgrzrTvzwE6Wil0Dftpt9bUf6BOrrn7AwwxW1QAvDwt8k2PXP6qt5HD?=
 =?us-ascii?Q?rKQecfK26PmOV6jn/qxnDZV6hcuMbDd/jdJoZi/REk131d+G1Kzf4Ec/pv5/?=
 =?us-ascii?Q?/V4uv2Z9wxMgNJmfn2CnoStKgYh1pX0gzp2BAoWjGzR0Npoto31UUeh8AOm6?=
 =?us-ascii?Q?tj1XjeEPzkhUEhI9KKVLVHJqP7AfSwyPowe8b5/AZybHYBxCHspxGkop8GTh?=
 =?us-ascii?Q?7Eb3ONURr9woEw27F5Tz6wUn9tlPXmevCTYidiu+Zh8T9Bul7zed68S6x5Uw?=
 =?us-ascii?Q?X1J2nWzNYjVPfU6iH61uh2zxFrI0wchlMbVuskjqTmts8eVSfBJRuUBSVZyI?=
 =?us-ascii?Q?Z3maH3u2+oPMsofc4350LZ1051FOqAOvn7ABwtyB02KQuwZX9CsB3dFJVqMz?=
 =?us-ascii?Q?Qo6tbAuB3HouvbQq77Oxb3Slcd54h9sFHNWjN43s?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 8fa519ef-16d0-4dd0-cb48-08dc74adae0b
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB5964.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2024 07:07:27.9046
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tg4PKOlVeMNnZzBSx0ipsP/H89RE4lhLkK35THN6c6yICyh+hLWeFmQz2eP6v5AJYVNMJVfkJjynI/ZneTtXcg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB8236
X-OriginatorOrg: intel.com

On Tue, May 14, 2024 at 12:11:19PM -0300, Jason Gunthorpe wrote:
> On Mon, May 13, 2024 at 03:43:45PM +0800, Yan Zhao wrote:
> > On Fri, May 10, 2024 at 10:29:28AM -0300, Jason Gunthorpe wrote:
> > > On Fri, May 10, 2024 at 04:03:04PM +0800, Yan Zhao wrote:
> > > > > > @@ -1358,10 +1377,17 @@ int iopt_area_fill_domain(struct iopt_area *area, struct iommu_domain *domain)
> > > > > >  {
> > > > > >  	unsigned long done_end_index;
> > > > > >  	struct pfn_reader pfns;
> > > > > > +	bool cache_flush_required;
> > > > > >  	int rc;
> > > > > >  
> > > > > >  	lockdep_assert_held(&area->pages->mutex);
> > > > > >  
> > > > > > +	cache_flush_required = area->iopt->noncoherent_domain_cnt &&
> > > > > > +			       !area->pages->cache_flush_required;
> > > > > > +
> > > > > > +	if (cache_flush_required)
> > > > > > +		area->pages->cache_flush_required = true;
> > > > > > +
> > > > > >  	rc = pfn_reader_first(&pfns, area->pages, iopt_area_index(area),
> > > > > >  			      iopt_area_last_index(area));
> > > > > >  	if (rc)
> > > > > > @@ -1369,6 +1395,9 @@ int iopt_area_fill_domain(struct iopt_area *area, struct iommu_domain *domain)
> > > > > >  
> > > > > >  	while (!pfn_reader_done(&pfns)) {
> > > > > >  		done_end_index = pfns.batch_start_index;
> > > > > > +		if (cache_flush_required)
> > > > > > +			iopt_cache_flush_pfn_batch(&pfns.batch);
> > > > > > +
> > > > > 
> > > > > This is a bit unfortunate, it means we are going to flush for every
> > > > > domain, even though it is not required. I don't see any easy way out
> > > > > of that :(
> > > > Yes. Do you think it's possible to add an op get_cache_coherency_enforced
> > > > to iommu_domain_ops?
> > > 
> > > Do we need that? The hwpt already keeps track of that? the enforced could be
> > > copied into the area along side storage_domain
> > > 
> > > Then I guess you could avoid flushing in the case the page came from
> > > the storage_domain...
> > > 
> > > You'd want the storage_domain to preferentially point to any
> > > non-enforced domain.
> > > 
> > > Is it worth it? How slow is this stuff?
> > Sorry, I might have misunderstood your intentions in my previous mail.
> > In iopt_area_fill_domain(), flushing CPU caches is only performed when
> > (1) noncoherent_domain_cnt is non-zero and
> > (2) area->pages->cache_flush_required is false.
> > area->pages->cache_flush_required is also set to true after the two are met, so
> > that the next flush to the same "area->pages" in filling phase will be skipped.
> > 
> > In my last mail, I thought you wanted to flush for every domain even if
> > area->pages->cache_flush_required is true, because I thought that you were
> > worried about that checking area->pages->cache_flush_required might results in
> > some pages, which ought be flushed, not being flushed.
> > So, I was wondering if we could do the flush for every non-coherent domain by
> > checking whether domain enforces cache coherency.
> > 
> > However, as you said, we can check hwpt instead if it's passed in
> > iopt_area_fill_domain().
> > 
> > On the other side, after a second thought, looks it's still good to check
> > area->pages->cache_flush_required?
> > - "area" and "pages" are 1:1. In other words, there's no such a condition that
> >   several "area"s are pointing to the same "pages".
> >   Is this assumption right?
> 
> copy can create new areas that point to shared pages. That is why
> there are two structs.
Oh, thanks for explanation and glad to learn that!!
Though in this case, new area is identical to the old area.
> 
> > - Once area->pages->cache_flush_required is set to true, it means all pages
> >   indicated by "area->pages" has been mapped into a non-coherent
> >   domain
> 
> Also not true, the multiple area's can take sub slices of the pages,
Ah, right, e.g. after iopt_area_split().

> so two hwpts' can be mapping disjoint sets of pages, and thus have
> disjoint cachability.
Indeed.
> 
> 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?

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.