Date:   Thu, 9 Mar 2023 11:59:59 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc:     Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Nicolin Chen <nicolinc@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "will@kernel.org" <will@kernel.org>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "kevin.tian@intel.com" <kevin.tian@intel.com>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "yi.l.liu@intel.com" <yi.l.liu@intel.com>
Subject: Re: [PATCH v1 02/14] iommufd: Add nesting related data structures
 for ARM SMMUv3
Message-ID: <ZAoCf9+kpMof6R+4@nvidia.com>
References: <cover.1678348754.git.nicolinc@nvidia.com>
 <364cfbe5b228ab178093db2de13fa3accf7a6120.1678348754.git.nicolinc@nvidia.com>
 <20230309134217.GA1673607@myrica>
 <213a05ef06944a55a148995053b187f8@huawei.com>
 <ZAn94BXkjiJKQ66O@nvidia.com>
 <39979642ba8042ba9d4de651fecfeffb@huawei.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39979642ba8042ba9d4de651fecfeffb@huawei.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bLkEbdodkOzRw6uMXNWnfrDiArjJ8pxfiSMeH+7NWkwy8KOeJnFMBf2P1DUx?=
 =?us-ascii?Q?YOtKA1wc2LkslnYs+NMXTwdl+el562CmHau+J6he/wskOlCtKCiHVD96gBPK?=
 =?us-ascii?Q?WJm8xpNVCqjd+XcXzzbASnAB0/BFHWla2gEmRi7CkA0oxxSrgNMIfz/giqj3?=
 =?us-ascii?Q?/MQ2Prtc9PcYyJoWH4AGh2BMrED9QddQovACZtIMIMHFKRl08QC3gFMdsPTL?=
 =?us-ascii?Q?HHQ0js8D8tlOon9oas45Y5gxl6tyGu+2mr07lyFrGiBIxMs8JPk0gwxTlUaw?=
 =?us-ascii?Q?GhdvRx6HYCmHRRrFcoX0YS5xyAccqOUlKYbK3ioS4mDMZd1pUg4Klb2xyzyd?=
 =?us-ascii?Q?ibQgIjbb1V6cEeqEgwxStGs9Zp0seIP3ZpWSQVVtdKqDR5dqW8TwdwK2Llbt?=
 =?us-ascii?Q?Ln72coK3bbRKZYx3xBhCZmvdQzRgnQZFKwjRKQocgzfVVxdDkKYiqDWSlkfl?=
 =?us-ascii?Q?jh6WHHMz3NS7V1gKMP8PuPjiCNAt1c9CHVH0qassZoXoMzMgMgiGb3ZGCNAp?=
 =?us-ascii?Q?s7REt3+SqzCk127xCkgzAEKYUIafp7qsJ89DVzfQFNOYPRvVTTGWdshu7KWV?=
 =?us-ascii?Q?CqWCKoY1jBORAlpO9dv7nz5tCgK1Hz5NPhwp0NxZXGGo+G1TIStdg+ntCNRT?=
 =?us-ascii?Q?Lg3bo0lDBHqocwWz9pgi1+u3KUGOgM/jhppL61uP7uQvpYNeSgX+pswGhDVo?=
 =?us-ascii?Q?4bL/+3MKOHwkFKeCUsZpbbvI92JwqDMCj8ilSi5X48LbTiMoLHVxKMAhO9/q?=
 =?us-ascii?Q?k+R7J4AOjQldHkyHXbrJM4xGdX812weHUI6Psn+rbrTvJ+kh553Fmabh4Q06?=
 =?us-ascii?Q?dE62coO/XZhZF2TuixZskGnO2HbWu8RAfuarut39Eky+cumuYjS7VjqDJKJu?=
 =?us-ascii?Q?9xmh0d9pxOU3VpabR9uPjG26j0ltkvYngUR+ViXQWv2u5oqXBi6a342rX+/r?=
 =?us-ascii?Q?d4F3pkDnvYTikfLZGmo8InhIg1/j/pwofGL9ELtVOs4WrRzZuRmeKsI2kWyc?=
 =?us-ascii?Q?cSBktfv0m7Y1hyaAM+nOucFuE0TFgeEtNWF20xeuFMkRLT1ClK7tjucc6gWl?=
 =?us-ascii?Q?iE+cydiT3yLdU7xKysKryfLnyXQJpNp5hKxdqaN0/bR0nu4cRDI77KQhwgmV?=
 =?us-ascii?Q?YXML5AtcKLMSVMVqky3a4CRYKAa/Ho5CmDczynz+AxscrMP4aACkyf20LDeX?=
 =?us-ascii?Q?CCI0qFD5KNLAIo1+0r9sMzGIC7BJGgZktSbxw+yT7yfWv/Ts059xLNI+mlZg?=
 =?us-ascii?Q?ENi7t3qMmOMm010Xt3pupDPQZcMkDgcb0ZcyVrGQBxN0OQ3SUPK8kBi3K/90?=
 =?us-ascii?Q?N4uSvX5GBsQwlHKcOYv5GnvfLXnYtjypE8DPPwi9qvHHi+kvpb5ghuqCw6DW?=
 =?us-ascii?Q?FarC//dvQ0jHN3q0FNoGZAJi8lBigABewpP5fq8mQZVKY4zuPJgH3b+/iu4H?=
 =?us-ascii?Q?f4LclpbWUwVn/7auob+bXVBnHDua8vtgPxcLoEDU3u+mB2fFD1SzJwzl6HrA?=
 =?us-ascii?Q?uV+eMB/XhkvGDAYvQr/iCz+/ur6RYPUtJRDdiUWDohAfs9U3tAa5cfGl89iE?=
 =?us-ascii?Q?Rttc+aTyAjQoeB77SI9kNXATfmPKVPasH7HCtztg?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a7023c7-2208-4b2e-44fa-08db20b757c8
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2023 16:00:02.7997
 (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: M7rwiOWg0utrfWVqNSHXgswJ2LXm/JecJCJC4LkDx84XARqyFU6G5BlvyhYTtiWb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7605
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Mar 09, 2023 at 03:51:42PM +0000, Shameerali Kolothum Thodi wrote:

> > For ARM cases where there is no shared VMID space with KVM, the ARM
> > VMID should be somehow assigned to the iommfd_ctx itself and the alloc
> > domain op should receive it from there.
> 
> Is there any use of VMID outside SMMUv3? I was thinking if nested domain alloc
> doesn't provide the KVM instance, then SMMUv3 can use its internal VMID. 

When we talk about exposing an SMMUv3 IOMMU CMDQ directly to userspace then
VMID is the security token that protects it.

So in that environment every domain under the same iommufd should
share the same VMID so that the CMDQ's also share the same VMID.

I expect this to be a common sort of requirement as we will see
userspace command queues in the other HW as well.

So, I suppose the answer for now is that ARM SMMUv3 should just
allocate one VMID per iommu_domain and there should be no VMID in the
uapi at all.

Moving all iommu_domains to share the same VMID is a future patch.

Though.. I have no idea how vVMID is handled in the SMMUv3
architecture. I suppose the guest IOMMU HW caps are set in a way that
it knows it does not have VMID?

Jason