Received-SPF: pass (google.com: domain of linux-kernel+bounces-209129-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 10 Jun 2024 21:28:39 -0300
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"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
Message-ID: <20240611002839.GS19897@nvidia.com>
References: <20240606182423.GF19897@nvidia.com>
 <ZmIDqgfINXfB0i3L@Asurada-Nvidia>
 <20240607002707.GJ19897@nvidia.com>
 <BN9PR11MB527604637EC37B3B03FBBE468CFB2@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20240607144917.GK19897@nvidia.com>
 <ZmN5WZkvDeIS7RRH@Asurada-Nvidia>
 <20240610120446.GP19897@nvidia.com>
 <ZmdbnGnp73yR36N5@Asurada-Nvidia>
 <20240610220110.GQ19897@nvidia.com>
 <ZmeGfqp26c3sGBmF@Asurada-Nvidia>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZmeGfqp26c3sGBmF@Asurada-Nvidia>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?PUcuk+8P+zgVB+u7eb8zceXN4wytP7/ueILOK8IQDSvjweL+LPf5JxBJjXxY?=
 =?us-ascii?Q?GPsFvppC2RGR5ZBTXwKE4E443YhrDlvfpSmtgAf34MdBZjnd53JVV0Gq3NT+?=
 =?us-ascii?Q?jSlLb1xEVhlretr1Yz20+Ppez/WnJL2D8IqRluchLJ3w6kObgmLolqGO0KEw?=
 =?us-ascii?Q?zD7uuj+CegKLJLrzLZCgsZncu6DcDuTXu97TOhJjowd2RKedTaH5YZCuA9sq?=
 =?us-ascii?Q?yrf9d13UQNI+TVr3IwLQ/JZloXdlYdNvG0/MYmm82ythjpfTE8ltPOld6eVE?=
 =?us-ascii?Q?ib3qBjOxLMVsDacDBjx0A0ipEhudA7PiSD+OoWsyceEaHvaUz4bGXhZ0D9yc?=
 =?us-ascii?Q?i0FtRhmCkj/oSbZ8qfx/zD/HcRd0LbsFTMr0F/a9eqXtQ4AoNFupSAPE3RNo?=
 =?us-ascii?Q?q2NiQYEPQALH4YnHz9BF2uyw/CX7cbU1MkV+orydSXvhyBn1EJhK30CW3wHL?=
 =?us-ascii?Q?3BuLAEpZGKgNybKpvktnlQZicDFhp+0TbAET9FQ/Chqov3wgz2fAYv/ECZMi?=
 =?us-ascii?Q?zOthg3PXr783WBDCpNvbOFdDFCMxYZVnfoYr/t7owSc5qDiyUcT8Jx8oFfCg?=
 =?us-ascii?Q?hwHwW5Y1UFOVq8/Afc/5+ImZAK78HcLZpgGGCfi6Thx/x5Bm59OxhWKbVbfi?=
 =?us-ascii?Q?DYSbVJZKZUT9xyE4ZBDh3cGKtGJwFBPRNfJqCnrGA/2h4m1m60iH8YxMJJTX?=
 =?us-ascii?Q?Fh3WRLW+1OgrgwiMq9VBa+e/6BaBNbskT7JqEnM53Z7LfvbwEYznbtE47nFF?=
 =?us-ascii?Q?gacYYyJWRy2sbOx5BP03cn4BaxMFQfBrTOVx7x3tdSV1tr6yAQJPaShtXjea?=
 =?us-ascii?Q?r+VltQe+8EpI48rXJoxeDDuERsWGZAYKKqACkP7DSrsJwJxiaipRrWwGdR+U?=
 =?us-ascii?Q?X5+ClkVCHDRW8Jweovq0sjb/8WxWzyHFVYqJ0BLDKJ2vAzSAZDATlpr+Hiqf?=
 =?us-ascii?Q?16OoKduQkZti/C5rKbdiagPsTSoqjh/5HtyTed6URQrOTnk9/CMKtNN5B7wR?=
 =?us-ascii?Q?KeRHo2kXiWgDB8kGZ5Gov2VWtaXJxBpiRoRugXZdJFGJmaxII2yqD1cOAkaN?=
 =?us-ascii?Q?JaGEbh3XFsujl0uhRtwzMB96t+jCayPpDC2Zdt77W0Iw4LFgt2pB93sGjpQh?=
 =?us-ascii?Q?1CqlyXd4orBgXc6L0sTtGsT1aa93uVol78UYu+uPo6evnWN+mHzQAilYwSH0?=
 =?us-ascii?Q?nFAuqH0SbZeSjx7PCuSQtwrsChmjfmlOKGgg2sV6uVEvyTVxmv0bUrnWktJA?=
 =?us-ascii?Q?yHgi5USDAvKD3FNrEgg1HR+nyhrAUArxQ8Bhu+W3EOtJVnn8NbEtA1rMuxSg?=
 =?us-ascii?Q?l1AJTd8WrEJvfbXkbUN3sBgceZMmv/Xa8Xhw4ieuw3pmq3GhjOUZGO2xJ9zj?=
 =?us-ascii?Q?M6HATrU/CFK4f6vmfY/ewmfzHEYMDSyLC6qQQ2tCSkb9mqa9bZwuhVhyhGDI?=
 =?us-ascii?Q?ht5JaE0o4HowHml9h8a3YXTxeEF4Pee3NI7hq00DmGgqVvv0UhxR2GvAMu9p?=
 =?us-ascii?Q?NP4Ch5fP1FyWF2caAmz/A2zvjVYz5nHdCpHlBc7G/x8xruCG1fYIGV5ZiZ0m?=
 =?us-ascii?Q?lEMrWxH5sbP0KhmGlmw=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 81437f83-072c-425d-2ef3-08dc89ad7237
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3849.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2024 00:28:41.9629
 (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: IZl4atCQUIJOesSlW+mELE+tyzpo9Te0SNZPxdIaZKlasLYfLf8aAC8vqlYkkdtB
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8565

On Mon, Jun 10, 2024 at 04:04:30PM -0700, Nicolin Chen wrote:

> > > Actually, even now as we put a dispatcher in VMM, VMM still does
> > > decode the CD table to link ASID to s1_hwpt. Otherwise, it could
> > > only broadcast a TLBI cmd to all pSMMUs.
> > 
> > No, there should be no CD table decoding and no linking ASID to
> > anything by the VMM.
> > 
> > The ARM architecture is clean, the ASID can remain private to the VM,
> > there is no reason for the VMM to understand it.
> 
> But a guest-level TLBI command usually has only ASID available to
> know which pSMMU to dispatch the command. Without an ASID lookup
> table, how could VMM then dispatch a command to the corresponding
> pSMMU?

It can broadcast. The ARM architecture does not expect a N:1 mapping
of SMMUs. This is why I think it is not such a good idea..

Yes the VMM could walk the CD tables too and build up a bitmap of what
ASIDs are being used by what pSMMUs, and that would be fine for the
VMM to do, but I wouldn't necessarily recommend it :)

Jason