Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Liu, Yi L" <yi.l.liu@intel.com>
To:     Jean-Philippe Brucker <jean-philippe@linaro.org>
CC:     "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "jgg@nvidia.com" <jgg@nvidia.com>, "hch@lst.de" <hch@lst.de>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "Tian, Kevin" <kevin.tian@intel.com>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "lkml@metux.net" <lkml@metux.net>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "lushenming@huawei.com" <lushenming@huawei.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
        "Tian, Jun J" <jun.j.tian@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
        "kwankhede@nvidia.com" <kwankhede@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "dwmw2@infradead.org" <dwmw2@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>
Subject: RE: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
Thread-Topic: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
Thread-Index: AQHXrSGQLQh7Daiwk0GPvXz/w70XfquwFdqAgAEXIGA=
Date:   Wed, 29 Sep 2021 10:47:04 +0000
Message-ID: <PH0PR11MB56589A10B7ED54CB59337ED7C3A99@PH0PR11MB5658.namprd11.prod.outlook.com>
References: <20210919063848.1476776-1-yi.l.liu@intel.com>
 <20210919063848.1476776-12-yi.l.liu@intel.com> <YUszZRk1vZOgVvFF@myrica>
In-Reply-To: <YUszZRk1vZOgVvFF@myrica>
Accept-Language: en-US
Content-Language: en-US
dlp-reaction: no-action
dlp-version: 11.6.200.16
dlp-product: dlpe-windows
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?wqMAjr5I8449M4GAiPNYyheopPUHC2L4o0YN7EO0X+TyNy+ILkAY96xsvcCF?=
 =?us-ascii?Q?5w5IwuHdGXrKbv9mCMyAQBTTPO0sM0/LiV4WBu/h/uFSGdHAmiDBT8+2VcSy?=
 =?us-ascii?Q?8VO7YB/C46p/Dci6qVPgVWq6Y+R1kcS3IYcuSmg8OgBv4yzlVSr1Em2l8u9j?=
 =?us-ascii?Q?+9n6hBaey82G8WHPkSMUIwHPRr7Dsz7ZWE9C6bHfnVyU9FuQ/iJhXHp0F/Dp?=
 =?us-ascii?Q?VXRqND+bYIoSzylsXccaPWeMR79yD/s2KRDMkdXpNqFOE2a34VQHk1fx9ehc?=
 =?us-ascii?Q?FrkJjOp9I3g8Fjfe7pxy4GCVaqNfayY/EBqhImJmHsMTqXGYHk+GSxlk5TND?=
 =?us-ascii?Q?CCuQon+qmA3s6CHBXPHfDOTf0O26kO9RX0R2EB3j0umgz5fhD9ZStlrDeKlv?=
 =?us-ascii?Q?Yyafz7PjFwhAEgNMPZeWq3v2WZ8pno+5Z+Q8OVz0GSSTUgxOStAqft4AC5nT?=
 =?us-ascii?Q?EgLph4tcvS5xvFevPwoJE1ztFhzZcfBzejqadqAE8qtRIEioW9puGpTe0rx5?=
 =?us-ascii?Q?FRP5chqH33p9eH+mQrLVLxm/lPWHa+4oSiGRfyBQg8MAz171zY0yZIqarytr?=
 =?us-ascii?Q?M4OyTB3Y+SUQ1eSRKM0v+vHfzsR9cCF02x8VIURsxJUgvE9rbV4KPjsue5GS?=
 =?us-ascii?Q?fa88fu2BsU5jlo3SXkIx3DLHKIMHSOqb8toxGDUdpLZ+jSZj3JYPzqNrg1A/?=
 =?us-ascii?Q?hjCFSQAaHmC++HEMeYh3ukxf2Wwmy8AbYLuCqWj/g5mBFB/gMNFAfOdBI+LW?=
 =?us-ascii?Q?QRyzxuwShR86fEnOeyM/iPGdPtT/C0VO4CPLMvq23BWTMuOXrPDBz+hqJ4Zi?=
 =?us-ascii?Q?oG8PgPxlUj2tTZHA6xkR5ySlTk38eIpbHBQ+1rOA8dBiBuWFp87VRGXn/uSW?=
 =?us-ascii?Q?U6vNUPWSDzIj7R7YVi3AfA6nbu0L1RJb/QUPwwr+NelPHsSzJI8cTw+whLzC?=
 =?us-ascii?Q?Xsg2t0eyGsjzVhUFfigiVXXJpl8qnSPskwnJNem51YqIM1n7LhlQcGpV+mKm?=
 =?us-ascii?Q?RYdAN0D4hT2cwZCMjDl21A8CC5s+piDxS8CnzhHiKYqabxxBdxEkebJ+1BpM?=
 =?us-ascii?Q?AupBoUK2zLbll678fnBvicKFky3zsTuVeuE1OxSHanH+U9i8mvupJgQTaIZI?=
 =?us-ascii?Q?WNqc0JWpBo4OFPtyzwIsCKiVDtkUYFSmJZQKidDIYreV8XtmEfPLiFOehYv7?=
 =?us-ascii?Q?PrgBH76HfCM6Vk6ByT1ncALGgXU5BZ9qGqjfcTAnV1nzxN3jypf8xvtiCK68?=
 =?us-ascii?Q?B7OciJrq+zXEQoG27Nd/nQXHCibX0Kbgpbo/a1YdPglbVn9gEplYMklKKaRX?=
 =?us-ascii?Q?DfNegXePweZrxTctYBXGT0Hj?=
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: PH0PR11MB5658.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 433a131d-69ce-4d4c-f571-08d9833679f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2021 10:47:04.4460
 (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: KwzzvqfORdMhv87Hqmz2QlfmV/R++YIMvZXoT+/Duf2ImGGBxUxU95+uOFkhLmvGPSLphXOi4pjat8Xri2HeRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5579
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Sent: Wednesday, September 22, 2021 9:45 PM
>=20
> On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote:
> > This patch adds IOASID allocation/free interface per iommufd. When
> > allocating an IOASID, userspace is expected to specify the type and
> > format information for the target I/O page table.
> >
> > This RFC supports only one type
> (IOMMU_IOASID_TYPE_KERNEL_TYPE1V2),
> > implying a kernel-managed I/O page table with vfio type1v2 mapping
> > semantics. For this type the user should specify the addr_width of
> > the I/O address space and whether the I/O page table is created in
> > an iommu enfore_snoop format. enforce_snoop must be true at this
> point,
> > as the false setting requires additional contract with KVM on handling
> > WBINVD emulation, which can be added later.
> >
> > Userspace is expected to call IOMMU_CHECK_EXTENSION (see next patch)
> > for what formats can be specified when allocating an IOASID.
> >
> > Open:
> > - Devices on PPC platform currently use a different iommu driver in vfi=
o.
> >   Per previous discussion they can also use vfio type1v2 as long as the=
re
> >   is a way to claim a specific iova range from a system-wide address sp=
ace.
>=20
> Is this the reason for passing addr_width to IOASID_ALLOC?  I didn't get
> what it's used for or why it's mandatory. But for PPC it sounds like it
> should be an address range instead of an upper limit?

yes, as this open described, it may need to be a range. But not sure
if PPC requires multiple ranges or just one range. Perhaps, David may
guide there.

Regards,
Yi Liu
=20
> Thanks,
> Jean
>=20
> >   This requirement doesn't sound PPC specific, as addr_width for pci
> devices
> >   can be also represented by a range [0, 2^addr_width-1]. This RFC hasn=
't
> >   adopted this design yet. We hope to have formal alignment in v1
> discussion
> >   and then decide how to incorporate it in v2.
> >
> > - Currently ioasid term has already been used in the kernel
> (drivers/iommu/
> >   ioasid.c) to represent the hardware I/O address space ID in the wire.=
 It
> >   covers both PCI PASID (Process Address Space ID) and ARM SSID (Sub-
> Stream
> >   ID). We need find a way to resolve the naming conflict between the
> hardware
> >   ID and software handle. One option is to rename the existing ioasid t=
o be
> >   pasid or ssid, given their full names still sound generic. Appreciate=
 more
> >   thoughts on this open!