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 17/20] iommu/iommufd: Report iova range to userspace
Thread-Topic: [RFC 17/20] iommu/iommufd: Report iova range to userspace
Thread-Index: AQHXrSGpfnufovxqLESc6zzFg8xwc6uwJ7eAgAq5dCA=
Date:   Wed, 29 Sep 2021 10:44:01 +0000
Message-ID: <PH0PR11MB56580CB47CA2CF17C86CD0D0C3A99@PH0PR11MB5658.namprd11.prod.outlook.com>
References: <20210919063848.1476776-1-yi.l.liu@intel.com>
 <20210919063848.1476776-18-yi.l.liu@intel.com> <YUtCYZI3oQcwKrUh@myrica>
In-Reply-To: <YUtCYZI3oQcwKrUh@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?wqU4Ob2xfdFvJ8tPjZGP8Cxf7hYvYUqenqthq2gy854JGt/dCaraRofe+pyb?=
 =?us-ascii?Q?bQBDRVyEl/hUJibp1DMvJv0Fo9BlZQG91H48xw9VYtk2DQoomrdUJiMoe2XL?=
 =?us-ascii?Q?60c9QhMb2P1iC1q4s9QfHAxu70tDi+Vgcbb0CxpZu0HjfJnZDnqqQ8KpNRaM?=
 =?us-ascii?Q?jR2MgGHwfvGkwagVV9qcF+ddnsxQ4QiNq31Lg5QWBTf0i/OR/Fn18fl0rniz?=
 =?us-ascii?Q?IQ+VTvyZzW2DRDeBm4eAKjxrmxCa83gHxAVj9W0QPUzjtor9kgjSq2LQdy+4?=
 =?us-ascii?Q?nu4cOYckl9drlhI3p251CJR8JhDLWOwf48HKvZ0t0b+lpRY8TlqwkFGdRP7j?=
 =?us-ascii?Q?BiefX7u3bnMTVcb/J0mTRj0uPLj1XI7JOD+9Lcmr9FB06fMwzFKmTqkHC1yy?=
 =?us-ascii?Q?9d32xkToMI4b+cL+yT1xWBiTc4f7Uqh7MiT68TBg0TVHcHAAgcBhEskXJpB/?=
 =?us-ascii?Q?9I5WZbLi58nRVsadcJGq9R7N/hHaQq42wqZ48zf6/+OG21tKGPEEgzzAeqvV?=
 =?us-ascii?Q?Nmcr9/ZseJfZje5kW8Sf1oE0yjXVKNbiom5IE2IuL0JExpRuSuO6eh1fBslP?=
 =?us-ascii?Q?IbW/RZ/3mUkKSkliW7jTtrOVDVTvfgX1heSFsq7SN7EfVIKiO7Thki8I+Ac0?=
 =?us-ascii?Q?7JmxzAhk09TbaClosAkz30fzq41vw5GZoxj+oEzX1r3aCvNi+hLfNKBZtEXb?=
 =?us-ascii?Q?yF0OLslsw4f3JqgQKqIFTBhJWiXQQNP+MKtMLCtUJKqeWKIcqPs0wzwZ87t3?=
 =?us-ascii?Q?Yndx0uStVutNA2JKRz+XbnaZ59LhPOUX8nDYVa7TqjQ6w16VDbhu1XijgyKM?=
 =?us-ascii?Q?W3GaeGvvPTmQA6sTC7uVNwctlT1dl0VhyIfvEx5FaCbOr+9mVbygHcvO8z2i?=
 =?us-ascii?Q?Pp7uhl8duxhiLyZ7fQ3plrNsHa4KTVs95EJh120gV91AokxjpIIS3B8I9ngG?=
 =?us-ascii?Q?1A+bp9JUTgkt3X0Pps+sX66byINnr141dBw011hMCQCZ7jJqRZFx8uJoRCJy?=
 =?us-ascii?Q?Xn7aQoIb3kFUgDAil1v4E1WTC48MA9oAwxuCg8tSn/k7nevtqOnbrDiUY48U?=
 =?us-ascii?Q?V6bFkbAlkQrfAWrUYGbLz3oD5MseZIDcplur1AqDdwDlFtDAQpNHWTdV2ikg?=
 =?us-ascii?Q?HtYeuzvYIT4jS21Wxnp+/DeNNrNlEF0WCWU4g2JD39lgvR9y9I45+1FY7fB7?=
 =?us-ascii?Q?aVIZfAo+Z4+F7NH8/m477WvvqQZ7emafWHFQPBteuW5grdPpHuLH8LrlHpza?=
 =?us-ascii?Q?OonLv6GhqbngPU7uE4nT7GL4Obas9ClT9DYYxeH5HW8f0xHDrsI4z8MKDTCt?=
 =?us-ascii?Q?PgFejOnYROaeUVan+h1NE36A?=
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: 9caa162b-cd3f-4a13-f477-08d983360c9e
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2021 10:44:01.1627
 (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: Rk5sMINXhu78CeUfhVTm5uaH0tGR3yugiW0fypKpw/GXlbAcMUtyrzeBP2c1+BOlHaTU2e7XNKa/XVQIONIe7A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5643
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 10:49 PM
>=20
> On Sun, Sep 19, 2021 at 02:38:45PM +0800, Liu Yi L wrote:
> > [HACK. will fix in v2]
> >
> > IOVA range is critical info for userspace to manage DMA for an I/O addr=
ess
> > space. This patch reports the valid iova range info of a given device.
> >
> > Due to aforementioned hack, this info comes from the hacked vfio type1
> > driver. To follow the same format in vfio, we also introduce a cap chai=
n
> > format in IOMMU_DEVICE_GET_INFO to carry the iova range info.
> [...]
> > diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
> > index 49731be71213..f408ad3c8ade 100644
> > --- a/include/uapi/linux/iommu.h
> > +++ b/include/uapi/linux/iommu.h
> > @@ -68,6 +68,7 @@
> >   *		   +---------------+------------+
> >   *		   ...
> >   * @addr_width:    the address width of supported I/O address spaces.
> > + * @cap_offset:	   Offset within info struct of first cap
> >   *
> >   * Availability: after device is bound to iommufd
> >   */
> > @@ -77,9 +78,11 @@ struct iommu_device_info {
> >  #define IOMMU_DEVICE_INFO_ENFORCE_SNOOP	(1 << 0) /* IOMMU
> enforced snoop */
> >  #define IOMMU_DEVICE_INFO_PGSIZES	(1 << 1) /* supported page
> sizes */
> >  #define IOMMU_DEVICE_INFO_ADDR_WIDTH	(1 << 2) /*
> addr_wdith field valid */
> > +#define IOMMU_DEVICE_INFO_CAPS		(1 << 3) /* info
> supports cap chain */
> >  	__u64	dev_cookie;
> >  	__u64   pgsize_bitmap;
> >  	__u32	addr_width;
> > +	__u32   cap_offset;
>=20
> We can also add vendor-specific page table and PASID table properties as
> capabilities, otherwise we'll need giant unions in the iommu_device_info
> struct. That made me wonder whether pgsize and addr_width should also
> be
> separate capabilities for consistency, but this way might be good enough.
> There won't be many more generic capabilities. I have "output address
> width"

what do you mean by "output address width"? Is it the output address
of stage-1 translation?

>
and "PASID width", the rest is specific to Arm and SMMU table
> formats.

When coming to nested translation support, the stage-1 related info are
likely to be vendor-specific, and will be reported in cap chain.

Regards,
Yi Liu

> Thanks,
> Jean
>=20
> >  };
> >
> >  #define IOMMU_DEVICE_GET_INFO	_IO(IOMMU_TYPE, IOMMU_BASE +
> 1)
> > --
> > 2.25.1
> >