Received-SPF: pass (google.com: domain of linux-kernel+bounces-139517-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Lu Baolu <baolu.lu@linux.intel.com>
CC: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>, "Robin
 Murphy" <robin.murphy@arm.com>, "Zhang, Tina" <tina.zhang@intel.com>, "Liu,
 Yi L" <yi.l.liu@intel.com>, "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 01/12] iommu/vt-d: Add cache tag assignment interface
Thread-Topic: [PATCH 01/12] iommu/vt-d: Add cache tag assignment interface
Thread-Index: AQHaflqwfTup1ArZ00iKq9wT+H7xNLFhvmwAgAB9uOA=
Date: Wed, 10 Apr 2024 23:14:30 +0000
Message-ID: <BN9PR11MB5276B57D6E72870C9B1798838C062@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20240325021705.249769-1-baolu.lu@linux.intel.com>
 <20240325021705.249769-2-baolu.lu@linux.intel.com>
 <20240410154134.GG223006@ziepe.ca>
In-Reply-To: <20240410154134.GG223006@ziepe.ca>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?NKymwp7GUjjU+Co8xaOqxGoKx8Jlo+GxVZh2FH2h2nmnMpzRLy0IdmpAoPtE?=
 =?us-ascii?Q?0LhxjUnZOa9DNZIuCRvQgAL0mmmH+mTNABgLIr/e2wMZHV1U2GEPElgNU5FV?=
 =?us-ascii?Q?EscphslA161wMnM5nntrmPw3llidUrpvmfsfTU9zWZavAn4AwN6hxIdgNs3D?=
 =?us-ascii?Q?TifwG9Bvf9PJ/kl01crE5xcDy3K/cPHMlnGpu4HUvguBuQHFs5mwRBLz3QFp?=
 =?us-ascii?Q?/z/yQLFBG1P6GGtl/YWY76n1pq8AbFotjYe07haYe6ONn0FvpGiWR6cn7Kyp?=
 =?us-ascii?Q?L4r2KiTYF+v6cYkQ/lQzxYp5EG6f5GsP7kvQ3K+Yzk9UCmOyEHVviLQk+/iw?=
 =?us-ascii?Q?k9lt+2QBrqKLRVjFMc9X9kgdNXdjzLuy9Q1egiPDbNLhDvxeXFjGUBIJVpfs?=
 =?us-ascii?Q?5vp6vmC90OGNVbmJNLQeehxhgFrdwukvy/JDPC6nLI4KnI9gWvt4L5kYhU7E?=
 =?us-ascii?Q?FO7dt9F4IQb2q8yuTye5LVDPxwCw7p8bhqzRLY0Q1d+sQZBbGtJ+PVV1wxwe?=
 =?us-ascii?Q?2HyfezyKxn0qsoNHhss1QblvGdQevEN+nylGrLLMnSKfAMCQYEq/ymD5U0zy?=
 =?us-ascii?Q?1hK7AydfE9uS7jTWaqrXVAlHPyM+sWgNBUf/cgQRvWZ+CbKTX5fI7WHuAx8R?=
 =?us-ascii?Q?EEn9z+jae/BYrUYdyF3viGVnwe6Hsxws+JtnH3uu1jtASDgxPCnQb23onpvi?=
 =?us-ascii?Q?Y6tarrAITl0ZsVCHTmSMtM9PJb4tOP7HYoMaDZ8GtMBT/Prb6zvoNLeGgZS4?=
 =?us-ascii?Q?1pQy5poGvk6jZsZjqbzw8OOo0HVxh+voxlfquqwswH8jMIQw9puII8dEI5jj?=
 =?us-ascii?Q?k/a4T598IYKkrQO1Gxt8Z998EM2gsqqgKeOEjlXAU0AHPQVrtwdDJnxSzklg?=
 =?us-ascii?Q?GfrgFqMowSNGa6cIezbxh2MRczwK5bOCsLW/UtadNFGlgbHcYJiJZ/A5loFg?=
 =?us-ascii?Q?LjKVfRv8tENBVZZXFZexAH0bvG/MJgr6Gdp6+9N3csvkDWzuFOXVeOkLnuoS?=
 =?us-ascii?Q?Y1RpEQDYAM3qMEQ7ugd4h2GQHT8lMCae/vyqjk9ZBBqAoCze1HsaUBnUmvXZ?=
 =?us-ascii?Q?gosfdWY05bu1xXkN+iCpZPf0QL7QZYQFvHqv4WqF+L3CLEWGC1TQuzVKr5OQ?=
 =?us-ascii?Q?lMUMC6AtJsE69yHJiqt/Ww2U+puIi1+d8m+T9njVBe4OeiFmKoGS/x5NSzfn?=
 =?us-ascii?Q?veJLynZeIFaeUaQj7ykb9GVBmnNX2vBN1ShSxMTj765DVqnrv4RdeskR8tye?=
 =?us-ascii?Q?im78GCbBSL/C7RHldDgwvSB8s5bMYaqNvpEieU2xW9sM1Hz4rgdFjq6Wj1kc?=
 =?us-ascii?Q?d9gRLhsHJG5zxXYZqhykZ6G8+LMV7yiKvLe6A4hH2sYG7Iui/ScdQNic/yGJ?=
 =?us-ascii?Q?Bz1XRjp4n9c7Q5HqJKyi0Sqvu5pDDF/eY/SS+kJA30YSKsXmtkgHCx3JzKek?=
 =?us-ascii?Q?lMFBWh81UoPXARVjaZIlW5Ch//ECf7WQgYXmHvXJQsKTTmqIXH3LQqRjVO+C?=
 =?us-ascii?Q?Pwz1vX80jPteu7XkYbzO/c6M7mhvAZw+gOaEHCdkX0AyxqHKj9WD2jSkOhjZ?=
 =?us-ascii?Q?bc/cacnCW79QnY85nvbt1x1ndLUPi8CZQX5rLHnz?=
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: 271356c8-0125-4d93-15d2-08dc59b3f9a7
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2024 23:14:30.1917
 (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: wH+V5Vb3EnhmDjLLcSK7zyPeSCjPUwQ4dczbRQn6HSKkyWFu/72c3S5k1a9HsNpwH+jSwZ1AxQK80Zu3DfDZ6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6055
X-OriginatorOrg: intel.com

> From: Jason Gunthorpe <jgg@ziepe.ca>
> Sent: Wednesday, April 10, 2024 11:42 PM
>=20
> On Mon, Mar 25, 2024 at 10:16:54AM +0800, Lu Baolu wrote:
> > +static int __cache_tag_assign_parent_domain(struct dmar_domain
> *domain, u16 did,
> > +					    struct device *dev, ioasid_t pasid)
> > +{
> > +	struct device_domain_info *info =3D dev_iommu_priv_get(dev);
> > +	int ret;
> > +
> > +	ret =3D cache_tag_assign(domain, did, dev, pasid,
> CACHE_TAG_TYPE_PARENT_IOTLB);
> > +	if (ret || !info->ats_enabled)
> > +		return ret;
>=20
> I'm not sure I understood the point of PARENT_IOTLB? I didn't see any
> different implementation?
>=20
> Isn't this backwards though? Each domain should have a list of things
> to invalidate if the domain itself changes.
>=20
> So the nesting parent should have a list of CHILD_DEVTLB's that need
> cleaning. That list is changed when the nesting domains are attached
> to something.
>=20

probably just a naming confusion. it's called PARENT_IOTLB from the
angle that this domain is used as a parent domain but actually it
tracks the child tags in nested attach.