From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>
CC:     "peter.maydell@linaro.org" <peter.maydell@linaro.org>,
        "lushenming@huawei.com" <lushenming@huawei.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        Jean-Philippe Brucker <jean-philippe@linaro.org>,
        "maz@kernel.org" <maz@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "vsethi@nvidia.com" <vsethi@nvidia.com>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "wangxingang5@huawei.com" <wangxingang5@huawei.com>,
        "vivek.gautam@arm.com" <vivek.gautam@arm.com>,
        "zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>,
        "eric.auger.pro@gmail.com" <eric.auger.pro@gmail.com>,
        "will@kernel.org" <will@kernel.org>,
        "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: RE: [RFC v16 1/9] iommu: Introduce attach/detach_pasid_table API
Thread-Topic: [RFC v16 1/9] iommu: Introduce attach/detach_pasid_table API
Thread-Index: AQHXyx+9zoVf6ec36EaoAw6mFm2RjKwlh1WAgAGLFwCAARJNAIAAUNaAgABaKgCAAEnegIAAE6oAgACHsjCAABVZoIAAzVeAgAED4rCAAGBlgIAA7M0AgAj9m4CAHKu0oA==
Date:   Tue, 4 Jan 2022 02:42:39 +0000
Message-ID: <BN9PR11MB52765F70759C3905177588768C4A9@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <fbeabcff-a6d4-dcc5-6687-7b32d6358fe3@redhat.com>
 <20211208125616.GN6385@nvidia.com> <YbDpZ0pf7XeZcc7z@myrica>
 <20211208183102.GD6385@nvidia.com>
 <BN9PR11MB527624080CB9302481B74C7A8C709@BN9PR11MB5276.namprd11.prod.outlook.com>
 <BN9PR11MB5276D3B4B181F73A1D62361C8C709@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20211209160803.GR6385@nvidia.com>
 <BN9PR11MB527612D1B4E0DC85A442D87D8C719@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20211210132313.GG6385@nvidia.com>
 <BN9PR11MB527694446B401EF9761529738C729@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20211216204831.GD6385@nvidia.com>
In-Reply-To: <20211216204831.GD6385@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?dGlUp7vLVMoS/st0FA52PzS+mp+szmnYAo2EoBW4OWCUKIbf2yQse+PGQ8jW?=
 =?us-ascii?Q?4/jNCbT4W5z7HG/+4DddVVbbxJwazue1g0p0i7Kl+pQXujy54QeOsmapA34Z?=
 =?us-ascii?Q?x6uIeeDO5AP1M2L8M0MlqYjumpay2+lMBF5XSlnSS+R9K/ZDWA/cQAtp+veF?=
 =?us-ascii?Q?1XDb7VTusL8XKcQet6grhQZcTIduoIAF/sDPVTCy2TGf+ia3vZ2KEw6n0D2f?=
 =?us-ascii?Q?6O4PjUtcZJ4GUFLvWVNo8zzuGpjlLEmNjtzqXZnHxCaphP8OrQPe/fuWrMme?=
 =?us-ascii?Q?QPvDv5Ui+GmxFCNkLIjc/AA9aut+Ys0SRwUg3ZgIcu63pnSHwnzJfKQSbZPA?=
 =?us-ascii?Q?EoFSQBrMJCEoPGik06CpOsY/8OdZAI6R0QKR55MfQm0cdT5qBwzemaHws+7S?=
 =?us-ascii?Q?jq89uIiWJHZvUPJ8kMlpZi3spti4zH5laaKLmaTomJFUXmr1dbVEeN9pIH51?=
 =?us-ascii?Q?xLmbikMs2+yjR3GCPiRvyi6Qcfyx1dUyXTzV2w3u8pvphuVNXwyDq1x+X4SX?=
 =?us-ascii?Q?Gb5hcq6cAUNq/bsvmNn20EbEa0qYHVkkqfstuF5Fz250HT12bxMSLgixvpzg?=
 =?us-ascii?Q?VPYJ39IHppLsy9IZ28W/r7JnF5f/fa5rQvZ4aW3jEIgZzngSy6Pk2ZWqi9+7?=
 =?us-ascii?Q?VyfFILkrVoraM+VDAI+tIE+I8IdTnO/3g7o1vhQdZkmGMarQqKrNL/TGW0mY?=
 =?us-ascii?Q?lEunW0z63wzxmrSfy/0J4rJBJBvveFsUq7T+qJgqTCEPzSoSbeu2WbOsSw20?=
 =?us-ascii?Q?i9pfL7lySVOnpgVQsfNEMZRmA4Nw82PYSjw3KvI2vmSgCJKC3My9bRBIEZtg?=
 =?us-ascii?Q?uK+x3qoQuhKpnNM3zRjouJPot+2LAgNJ16YNBaJmLXABiBxLRWAnCM2xHA6o?=
 =?us-ascii?Q?EhO+90+qEGlVf/HIVTh1JszeuPypPc3k/iXLuSdiIkP4KGpg6SxuCaBLKr+U?=
 =?us-ascii?Q?75trXkvVJqT6+1Qk37750cC0fMwiTSVtQ/4jfrH76LDDvWaFnY/8A+ZLkwCu?=
 =?us-ascii?Q?SAb65gszG25SmpTs4e3Zx4UWir20fBRKxgK1BHAv3auMXx1a1g66F7aweqlN?=
 =?us-ascii?Q?qRPYlYuaj0MjFHrqevmbnQSGQq4KfdfDOYvo2Y06kBx5fi1wzwprbIOE4uyi?=
 =?us-ascii?Q?m+LTRwHhpRSvLvp+NN6rWosxImfa5ZtrVJ5Jq3IVHEgV0qAshtRFMGmhNRY4?=
 =?us-ascii?Q?16PJmwyW9+i8CcsE/B0qSy4occYksalOSnsrEXRYCxyu9ie5uyZe07pNKhlt?=
 =?us-ascii?Q?L/GsmVhXiGVszVHGyU+A0dOT+8rY1L18hAzNpjFPANGm5zwZc979DFC9NqV8?=
 =?us-ascii?Q?61aDBpJl/dwO1lNe88hbcVIjKwYaA24O0euHn4q6IT74tQ6PpOOWVeQpHyNg?=
 =?us-ascii?Q?LuBaZF9LG/N8Nq5+I1pPvhew4tln3UGvQp8qHqaMdSgBhP9ghuyliMmtVR/8?=
 =?us-ascii?Q?7gqg9R+BNGvbi9hsO6Xa8Kp6UvtWGtG1ccEKlOD4Luq6p3RonfSovfEPQrw0?=
 =?us-ascii?Q?4yMBXcB7nzdpgcBIhVuyeP5F8N7hC0rB0VYk0GVKrZ1iasZNb75sdfjl2sCf?=
 =?us-ascii?Q?TngMzi3sq4blDR9yxYDbhFDeUlwpSxNNphjcUriKsoGmKvv+7jwoJ1H32dsr?=
 =?us-ascii?Q?1PYBp+MzjnTjf7biJxa28so=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 1c996295-63c1-44d7-f6ba-08d9cf2bdff2
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2022 02:42:39.6823
 (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: F807j9kmC+t0SZJtwEOKbwfMnHMN75iGDubU4pTawlmORIyoHj19ieq8d1sF7+gNRxQqsrEF+Jv3KJ+w49dMKg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3937
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, December 17, 2021 4:49 AM
>=20
> On Sat, Dec 11, 2021 at 03:57:45AM +0000, Tian, Kevin wrote:
>=20
> > This might be the only open as I still didn't see why we need an
> > explicit flag to claim a 'full device' thing. From kernel p.o.v the
> > ARM case is no different from Intel that both allows an user
> > page table attached to vRID, just with different format and
> > addr width (Intel is 64bit, ARM is 84bit where PASID can be
> > considered a sub-handle in the 84bit address space and not
> > the kernel's business).
>=20
> I think the difference is intention.
>=20
> In one case the kernel is saying 'attach a RID and I intend to use
> PASID' in which case the kernel user can call the PASID APIs.
>=20
> The second case is saying 'I will not use PASID'.
>=20
> They are different things and I think it is a surprising API if the
> kernel user attaches a domain, intends to use PASID and then finds out
> it can't, eg because an ARM user page table was hooked up.
>=20
> If you imagine the flag as 'I intend to use PASID' I think it makes a
> fair amount of sense from an API design too.
>=20
> We could probably do without it, at least for VFIO and qemu cases, but
> it seems a little bit peculiar to me.
>=20

ok, combining the kernel user makes the flag more sensible.

Thanks
Kevin