Received-SPF: pass (google.com: domain of linux-kernel+bounces-205188-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>, Nicolin Chen <nicolinc@nvidia.com>
CC: "will@kernel.org" <will@kernel.org>, "robin.murphy@arm.com"
	<robin.murphy@arm.com>, "suravee.suthikulpanit@amd.com"
	<suravee.suthikulpanit@amd.com>, "joro@8bytes.org" <joro@8bytes.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, "linux-tegra@vger.kernel.org"
	<linux-tegra@vger.kernel.org>, "Liu, Yi L" <yi.l.liu@intel.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>, "vasant.hegde@amd.com"
	<vasant.hegde@amd.com>, "jon.grimm@amd.com" <jon.grimm@amd.com>,
	"santosh.shukla@amd.com" <santosh.shukla@amd.com>, "Dhaval.Giani@amd.com"
	<Dhaval.Giani@amd.com>, "shameerali.kolothum.thodi@huawei.com"
	<shameerali.kolothum.thodi@huawei.com>
Subject: RE: [PATCH RFCv1 08/14] iommufd: Add IOMMU_VIOMMU_SET_DEV_ID ioctl
Thread-Topic: [PATCH RFCv1 08/14] iommufd: Add IOMMU_VIOMMU_SET_DEV_ID ioctl
Thread-Index: AQHajVVl26WkVBqVE0qDV+tml8yTY7Gkmr6AgAGEQoCAABbGEIAAaX4AgAPpupCAAtXxAIAAbUsAgAAHhACAAV8OUIAAC42AgASA5ICAAfF7AIAFsh+AgAAFwACAAF+ZgIAAAdLw
Date: Fri, 7 Jun 2024 00:36:46 +0000
Message-ID: <BN9PR11MB527604637EC37B3B03FBBE468CFB2@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <BN9PR11MB5276BBD592021507C3A0EBB38CF02@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZlY886FT3HHLC8Cf@nvidia.com>
 <BN9PR11MB52762EA9B444DA71F551C3868CF22@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZlafEktUu5znDsNt@Asurada-Nvidia>
 <BN9PR11MB5276AC43120376A2502D3D148CF32@BN9PR11MB5276.namprd11.prod.outlook.com>
 <ZlfPPwsnY6P4SoGF@Asurada-Nvidia> <ZluWXYQjroz0fqqn@nvidia.com>
 <Zl03rsgZl/msa3I+@nvidia.com> <20240606182423.GF19897@nvidia.com>
 <ZmIDqgfINXfB0i3L@Asurada-Nvidia> <20240607002707.GJ19897@nvidia.com>
In-Reply-To: <20240607002707.GJ19897@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CVyBR5dndsxzz4GK0hRCBXkXrFmKuYgsYQ9iUWp2ZItooVKK6JBSKtCjEkLW?=
 =?us-ascii?Q?orqhgvIFFuBJYGrrdDnW0rACmSR2wnwKhLkZJiylGYLTs29xIZPbUf90sAvc?=
 =?us-ascii?Q?FKqx/7mnfSjF3yOGKemCifgD5ROH0WFosfTO3w15AlcKG/F1TC8yLnsAwjeR?=
 =?us-ascii?Q?jHHF2RnhfyZLrX01X1rmvkRSowwX8AtLk2cqhho8yWMZjCdMUdSIc4/G0lnZ?=
 =?us-ascii?Q?omG22La/z/RmgucVNonm6qGOIC5TYpId1RR2MmfHM9SpOXWB2J3zubGWgIPE?=
 =?us-ascii?Q?i1FUNqUclRldSDYa4wxC2TaQMb/qQ3fVQf1w48v4Og9ikyr1BoUS0jp9b8RS?=
 =?us-ascii?Q?0r/B6WktGBbxhegP8L2yiqY2V8QmDM8wUpfrpG0PyqhzcwUgAY4U88NiRREE?=
 =?us-ascii?Q?ZA9JOtr5PNa8YSkRgDS8eu4EXPI79ZMaBMM0tii/p+wEdOc8qfNcT4T07loZ?=
 =?us-ascii?Q?3xS5CQdNYFQU9gePBxFfV54QJnSn9gdrvRzCU/BZJa28cbNo2pfQPs9u+Z9T?=
 =?us-ascii?Q?D9aEItLFtzkRuXtHr2XB5v6yB1s2njQKrq1czY0ugNovrvluzpD5lGIDaphN?=
 =?us-ascii?Q?ru1b4E3Wlr9zVhDzetkeBrd0dxD4SleXZl9AZ2u6T7xANLNaTC0b5ogv7SW3?=
 =?us-ascii?Q?Q/WP7jmi4xxuaEsxYLuH49nTDOZkthLIaC+gBgptWowytlm2/nxWyE0JTcpD?=
 =?us-ascii?Q?qZz6qCSe7gqw4rK5Ld38Y/O59XNKHxmHghkGjRij9NgMLAqvm2s1TUNFaiYZ?=
 =?us-ascii?Q?VRAUzkGWv/LeD/Jl05ycgV02CG+JaTW3JkucbJD+JR02Amv/LqZ5575IR+cu?=
 =?us-ascii?Q?QXJE9y/dWzSH0PezMARljZL3BSm80STofb3aQgZTLlaFd88l+VDR/jPhUJwS?=
 =?us-ascii?Q?PhOzDT+bSJxjpbqn8JGgk8svb3M5VDdq4qp6GU7prdvEFCei2rhQUBNkDLa3?=
 =?us-ascii?Q?44A51sOCMDDqaioHiwtjmciYzyD061m9J4Xd2EPPa1fuNFEKst+AaahHGYI4?=
 =?us-ascii?Q?Rk0Hog/WDqe/JAnmHCEsfieIBSoBFLPQWFt8k7Kdut5binGokzXANxBmsFJc?=
 =?us-ascii?Q?ks0nsxB7LnWv/3ETYNu04aTi4EGbdHf+FUJwgl0YyM65Nv7r3vJEi5Vi2cPm?=
 =?us-ascii?Q?3V4w0paP34z95pinVYDYjSnqFMUm7DUWrJc6xlv+mLagxctMe5iA/RGIhimt?=
 =?us-ascii?Q?U59p14P0rih38JMmmNd8wiaUTMtKO6aeZsM46F3qE65tLv8tCoa3KFA1fSjI?=
 =?us-ascii?Q?WGgFyOTXOgZdAVePoIxm66wU26D2Bai6WMwZ3SXeZzMKBvALt4RiR8TOWhiO?=
 =?us-ascii?Q?x7xUsEYmBu4B0Xv8PcN5Xxlj9zcr7KY7XMkS5JJBmMtjhtG219k0gbQQodd/?=
 =?us-ascii?Q?JFsHKTWACX/pd7sn9rCO9IAxKg/Cp0mIrVfCy/4gk6D1toTQm98op7vQK2jx?=
 =?us-ascii?Q?pWKfGuL1ICBcodTxi24R9hoaGAMW2IevuDq1FJ9IBBIhplb2Z5joZ/Mxh4Sm?=
 =?us-ascii?Q?oRFeyBXfGViBT2WPcLcv5ELG4XS9CjszLM37Imgyghu6LfcMtQvPUqJHE44Q?=
 =?us-ascii?Q?3OECvCLh6cgLIPl2eMGa8uJ8lIc8QXf4ubVFNTdt?=
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: 83b05a62-5477-4c11-bdcc-08dc8689e97c
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2024 00:36:46.5409
 (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: wUrOfvpqi1RAixQj30TPtZStn8jkF5evlFvRM3BF9ouS3qcrO3dJ8ampsuJ+QGviU5Lu7ChhRZ1jhNlo3cANZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4617
X-OriginatorOrg: intel.com

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, June 7, 2024 8:27 AM
>=20
> On Thu, Jun 06, 2024 at 11:44:58AM -0700, Nicolin Chen wrote:
> > On Thu, Jun 06, 2024 at 03:24:23PM -0300, Jason Gunthorpe wrote:
> > > On Sun, Jun 02, 2024 at 08:25:34PM -0700, Nicolin Chen wrote:
> > >
> > > > > I understand the appeal of doing this has been to minimize qemu
> > > > > changes in its ACPI parts if we tackle that instead maybe we shou=
ld
> > > > > just not implement viommu to multiple piommu. It is somewhat
> > > > > complicated.
> > > >
> > > > Would you please clarify that suggestion "not implement viommu
> > > > to multiple piommu"?
> > > >
> > > > For regular nesting (SMMU), we are still doing one vSMMU in the
> > > > VMM, though VCMDQ case would be an exception....
> > >
> > > This is what I mean, always do multiple vSMMU if there are multiple
> > > physical pSMMUs. Don't replicate any virtual commands across pSMMUs.
> >
> > Thanks for clarifying. That also means you'd prefer putting the
> > command dispatcher in VMM, which is what we have at this moment.
>=20
> Unless someone knows a reason why we should strive hard to have only a
> single vSMMU and accept some invalidation inefficiency?
>=20

migration? a single vSMMU provides better compatibility between
src/dest...