Received-SPF: pass (google.com: domain of linux-kernel+bounces-141849-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
CC: Baolu Lu <baolu.lu@linux.intel.com>, "iommu@lists.linux.dev"
	<iommu@lists.linux.dev>, "Liu, Yi L" <yi.l.liu@intel.com>, Joerg Roedel
	<joro@8bytes.org>, Will Deacon <will@kernel.org>, Robin Murphy
	<robin.murphy@arm.com>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/2] iommu/vt-d: Remove caching mode check before devtlb
 flush
Thread-Topic: [PATCH 2/2] iommu/vt-d: Remove caching mode check before devtlb
 flush
Thread-Index: AQHaiPoC7RpD2axGS0qZEPwCpJ1HeLFe3nWAgABnDgCAAPAgAIAAdL7wgAEJg4CAAHVPwIABHHCAgAC2WnA=
Date: Fri, 12 Apr 2024 03:13:33 +0000
Message-ID: <BN9PR11MB5276A2DFFA8C523EA1C148968C042@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20240407144232.190355-1-baolu.lu@linux.intel.com>
	<20240407144232.190355-2-baolu.lu@linux.intel.com>
	<20240408140329.6290377f@jacob-builder>
	<aff42b8f-b757-4422-9ebe-741a4b894b6c@linux.intel.com>
	<20240409103146.0d155e45@jacob-builder>
	<BN9PR11MB52763F42ED6719E6D03D0D308C062@BN9PR11MB5276.namprd11.prod.outlook.com>
	<20240410091955.5c00e411@jacob-builder>
	<BN9PR11MB5276DDE04A315B1F870872468C062@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20240411091749.20afae6b@jacob-builder>
In-Reply-To: <20240411091749.20afae6b@jacob-builder>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?RI8y1iYZ5ebyn8ukQRbqa+lWTExenkoVtaCarkV9svGtGmS9ntw2Iu5vTiUe?=
 =?us-ascii?Q?uWIsA1AYgjhwxyxBllkDM3Ftj3vBXBOTqXPGzDhWYAvCeQt1TCBCOK8GdMKo?=
 =?us-ascii?Q?BjHSAev08K+vX5OfREUKbMYMnyvfNMYqZjgnrI7LEiOO26KGL3R/KidyQka1?=
 =?us-ascii?Q?Vhu3aE1ICN3OzGt4qfNDXerOeaqd0dSeIQjx55AWx6QjgeUXkPzSyKRdMhM5?=
 =?us-ascii?Q?gHwyQxI1zLAAHdVDUrHfksDVKbvJ2L4GkNXPNmBvVeusBUdb8RH8iisMrZA4?=
 =?us-ascii?Q?yjQCZ46a4xGlrLIDI+6AwNO5YpRsM7bfrAKNvKpeulk4huJ2ZBpDkv7Z/QsG?=
 =?us-ascii?Q?g2GE6l/PNJ8vynKr11RkP2zfFq78YxDH2LEijFJL4RVC8AiS7svS46aHzc1V?=
 =?us-ascii?Q?a/IbgzaimGWS445unf6sgD9exP6zlUJQdSTqXEqDvIAI9z/cmfSRsfR4rKc+?=
 =?us-ascii?Q?M1NfAp/xXNjTOI/CQz2ZTrmL7/mXa2Gs57n3xGVAFhcJe3pLuczMiY34h8Ad?=
 =?us-ascii?Q?KKI1sbaIMJObBRbFFzr5NUCUHta78z1peBDafcZP8E593C6X1rP3dJYC4cJg?=
 =?us-ascii?Q?7yErHBB/ZNTLkNQWaxvb2FLr8VuMFqVauD1ke8UFIKRbDYyCEreWJ8rpmYeB?=
 =?us-ascii?Q?PWrvSoJs3C3ocBfeP/clcp29wGE0kzqPocP5KRnbJvmtFWVxjMCAzY939XJt?=
 =?us-ascii?Q?dVRor1eM8BujD6TDE7mMmm6nbe73rF04xqyghu2e8uRd9CspO3sF7wM6zx+8?=
 =?us-ascii?Q?L+cT2kLyS2Gr6AJQQT6uJFHhOqTmsgHaDuGWlrLZf1x8SZxm381q/RYRu9IR?=
 =?us-ascii?Q?hsDy4AXkbzotEWnUok8WjbqMTBe3waci47SqFy9nN/fq5nd3Iev5kc3dULxe?=
 =?us-ascii?Q?JY08zzJzpsl4U8aTkUUjkPcaKwPnukCCDEVkeJRpWHE2lsNTj7vKK9PS6AoL?=
 =?us-ascii?Q?GypBAfzyjKbj8HbUNhxj+OFNZV5JVR3dFCA+xgctqbvy2p2IQ9u8It/GAHIM?=
 =?us-ascii?Q?u3RZfiofIyT3kOezmXUJQI38cdEER+m3S1tCyGZb8FS7S5q0pw41d27Wxc/a?=
 =?us-ascii?Q?mAFqRsuY9I+ByVEqsA5wtIEglpIVnBQpsKDiNbiLvzCm0tDXSubYGM3K1pit?=
 =?us-ascii?Q?MU4Qlb+rmap7HqIg3rwh6jfXCfWxMtaJoMB4IX7V+2DLXEC310GSFuFDQlqM?=
 =?us-ascii?Q?MKGqt+0T71rfw0uYK+OirT5Ggg4FQdLYG9/GdrGoOsn8uhKu6ffDaAKgzMVb?=
 =?us-ascii?Q?Um/xzqxBTFjkTDavFMnrzt0RjvvOJfoSowXTOhFfK/nP4822QiMHx+tmcfy1?=
 =?us-ascii?Q?L4u/pAzcgNp0Av2YEWN/fRLhs7M8eLSJFSCTp+76uMEemXShFq+pDOagQ4Ej?=
 =?us-ascii?Q?qSQ7nzPJfY5w9wmzJOmzrfUGHZBVn/rrDoZUC28D2zZnTpO5/OE/+dBpiDSI?=
 =?us-ascii?Q?dInofMrQvuUax463kLmrWqwkf6ff9vraSl45EQPPF1k/6Jd5fuWwXwXTeDaI?=
 =?us-ascii?Q?hnhT1VN42eXKhLdSQbjQMazb1u/pKhg70US141nC4rOePSXq5hwa2hCz2G/L?=
 =?us-ascii?Q?xuoQsKoMpI3yqtaMSG2nLONlqqzhaDH3lggp8KyE?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2820d640-800a-4c54-3d10-08dc5a9e8979
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2024 03:13:33.7196
 (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: cFzg1lOBNd6F9ReqVigGCXAVLRaLIelTQNOaZPnMC9rmuPSBcqT9FWfqjbd3z/p1Y45yoidCnHtim8JtAUqktA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB5163
X-OriginatorOrg: intel.com

> From: Jacob Pan <jacob.jun.pan@linux.intel.com>
> Sent: Friday, April 12, 2024 12:18 AM
>=20
> Hi Kevin,
>=20
> On Wed, 10 Apr 2024 23:23:57 +0000, "Tian, Kevin" <kevin.tian@intel.com>
> wrote:
>=20
> > > From: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > > Sent: Thursday, April 11, 2024 12:20 AM
> > >
> > > Hi Kevin,
> > >
> > > On Wed, 10 Apr 2024 00:32:06 +0000, "Tian, Kevin"
> <kevin.tian@intel.com>
> > > wrote:
> > >
> > > > > From: Jacob Pan <jacob.jun.pan@linux.intel.com>
> > > > > Sent: Wednesday, April 10, 2024 1:32 AM
> > > > >
> > > > > If the guest uses SL page tables in vIOMMU, we don;t expose ATS t=
o
> > > > > the guest. So ATS is not relevant here, does't matter map or unma=
p.
> > > > >
> > > >
> > > > ATS is orthogonal to SL vs. FL. Where is this restriction coming
> > > > from?
> > > For practical purposes, what would be the usage to have SL in the gue=
st
> > > and ATS enabled. i.e. shadowing SL but directly expose ATS?
> > >
> >
> > ATS is about the protocol between device and iommu to look up
> > translations. Why does it care about internal paging layout in
> > iommu?
> >
> Maybe the original intent was missed, I was suggesting the devTLB flush
> should be based on ATS cap (as you said here) not map/unmap.
>=20
> -       /*
> -        * In caching mode, changes of pages from non-present to present
> require
> -        * flush. However, device IOTLB doesn't need to be flushed in thi=
s case.
> -        */
> -       if (!cap_caching_mode(iommu->cap) || !map)
> -               iommu_flush_dev_iotlb(domain, addr, mask);
> +       iommu_flush_dev_iotlb(domain, addr, mask);
>=20

We need check both, as devtlb doesn't cache non-present=20
so the invalidation is required only for unmap.

Here just the check of caching mode is irrelevant.