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:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Shenming Lu <lushenming@huawei.com>
CC:     "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        Jason Wang <jasowang@redhat.com>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        "Jean-Philippe Brucker" <jean-philippe@linaro.org>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        Jonathan Corbet <corbet@lwn.net>,
        "Jason Gunthorpe" <jgg@nvidia.com>,
        "wanghaibin.wang@huawei.com" <wanghaibin.wang@huawei.com>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "Alex Williamson (alex.williamson@redhat.com)" 
        <alex.williamson@redhat.com>,
        "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
        David Gibson <david@gibson.dropbear.id.au>,
        Robin Murphy <robin.murphy@arm.com>,
        LKML <linux-kernel@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>
Subject: RE: [RFC v2] /dev/iommu uAPI proposal
Thread-Topic: [RFC v2] /dev/iommu uAPI proposal
Thread-Index: Add0lrMH87IsTsl5Rp6WN1oQU6kGMQEkayMAAADgu8AABbP/AAAAaVlQAAzVHYAAAm93gAAC/CGAAAII8oAAAftjAAABDbYAAAAstAAAAGyhgAAARNiAAAwRJHAAGeRaAADmMRBw
Date:   Wed, 21 Jul 2021 02:13:23 +0000
Message-ID: <BN9PR11MB54332CA3CF19835A7B2742688CE39@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <a8edb2c1-9c9c-6204-072c-4f1604b7dace@huawei.com>
 <BN9PR11MB54336D6A8CAE31F951770A428C129@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210715124813.GC543781@nvidia.com> <20210715135757.GC590891@otc-nc-03>
 <20210715152325.GF543781@nvidia.com> <20210715162141.GA593686@otc-nc-03>
 <20210715171826.GG543781@nvidia.com> <20210715174836.GB593686@otc-nc-03>
 <20210715175336.GH543781@nvidia.com> <20210715180545.GD593686@otc-nc-03>
 <20210715181327.GI543781@nvidia.com>
 <BN9PR11MB543337BAEA86708470AC1E0C8C119@BN9PR11MB5433.namprd11.prod.outlook.com>
 <013e240d-f627-3565-aba1-71b2d6f514b4@huawei.com>
In-Reply-To: <013e240d-f627-3565-aba1-71b2d6f514b4@huawei.com>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.5.1.3
dlp-product: dlpe-windows
dlp-reaction: no-action
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?49012AVdhYducYe7s9uGFGgeuettVTQmyGBLjlWrz9JBwQxt664t0WlzKGKH?=
 =?us-ascii?Q?kh6poTWAjqhg5xFIOkPw4VdIt+F0UY4noe7uA0Fms3jilpZJ6zT5xt3eSSZl?=
 =?us-ascii?Q?OHV45NzGzypbrt6geSKTVmPpLrI/a98wIbm/uUw6hSOg9AHF7FmNG98+tUTg?=
 =?us-ascii?Q?7JTbfMJaG+WlVhbjvNe0bnN3gbNMztq2fs879lkmgqGd7kxX7NnVazoK+7iq?=
 =?us-ascii?Q?qeQEzx/R03hMT/ru8wheg+Q32csMjCeeKJPWLesouYB2OKtIflWHroTvChR6?=
 =?us-ascii?Q?AbUYp5Op/AmZODos4AxhWNjscTzjoj0voEPO+c3oF75H4bFdTEj8pJcGhbqN?=
 =?us-ascii?Q?+lIROw3MOxxyQKyr4jusG+R1PVAW00QWn7ykbtVUl6tJ26b63hOw1PF67+z5?=
 =?us-ascii?Q?tkyNbjCJybxH4NeMHnLUM6PuzgfEqd6W+IHz13CHskFepUTBPMnLZPhQGV3E?=
 =?us-ascii?Q?BRCEDRyo3rfxQl66JFQ8wYBS57b+tjpNsi8wVFfZCmZCirzFwEZTf3vLhPCh?=
 =?us-ascii?Q?xTCbLgSvnGCQmBsC3D+xRmS3//pN5eEASiNyjiix8H8tTQ3HjMzQGcmK34BZ?=
 =?us-ascii?Q?0+AiQOhO8TNLGv60cAkp3bJveM1+pW5Z1G8q0FpE3897MuxjY5JSnteqd/uE?=
 =?us-ascii?Q?kS6mYtxfmBQ9d8QbrUyvlNh5lEyWJcK4NafUNlLo7He1cRTDmnICgFsBZvbw?=
 =?us-ascii?Q?RjFP59miqEWVEfKgvDiP+4b0BZ9M4u6hk1+SJ7ml9Jj+WuGK10XyXlxVeNky?=
 =?us-ascii?Q?atz5A3A3YLC367jYa7F/bgI15FCO3xAuesRf3q83PK+PPMgiKYaMnRBy1dRw?=
 =?us-ascii?Q?nMyKcFCMV0kItfsd7Yddo5OqVywlFPcMYECNSB2pKhhTR1UV4h/Ebw/d6rOB?=
 =?us-ascii?Q?y3P2Sudh0hlrkMnO6h8OngKIQHY2ZW055WU+l4IThY5N2ZRA9f5yV5Wq1U3l?=
 =?us-ascii?Q?zv81DIvRdNTXOKLaXZZnf9BwE3x15fTa25tvl6ZHSzSZzjY7+OBVYvDsn75z?=
 =?us-ascii?Q?+Zl5X8Vq4fyIkTQCJiieRQovu+oBrz1ba31kL1t3D0oz3+w8ceAOdbPFQSjC?=
 =?us-ascii?Q?Sq61ZdaHXc9Tc0vH/6NAFIVIIrsuNAD6LHnvt2MXDDAOPdgTQmYy/4XAo6U3?=
 =?us-ascii?Q?TkRC4HQoBQKT3w0LdFAaja+5arFcqZzs5UKmZ1zRBImoYQCBEinb/zAXGcIH?=
 =?us-ascii?Q?Oyr/gaSZijwF1KMSWmt8n6/pefky6BcdIPkIn5IMK3kuMLTZJobshQvCHDj7?=
 =?us-ascii?Q?8iz/l7/9xWomvgeyDId8QKVU3XSG5F8cSnxZEbYZIAB0zADo7FIjxsgDuFP5?=
 =?us-ascii?Q?b4kwzGNUqFEc5PTwlalRoI28?=
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: BN9PR11MB5433.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b6560f60-da2e-4098-1857-08d94bed1e0f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2021 02:13:23.2258
 (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: 5/Gw5+Vx3/zU/r9E7hnkFleX4qUjSoQo/pfEVWX5QTFcVlDtrJVV1gFW6PrChjcCOgq0Hd9ZNOo/GC7pXSltmw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2291
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Shenming Lu
> Sent: Friday, July 16, 2021 8:20 PM
>=20
> On 2021/7/16 9:20, Tian, Kevin wrote:
>  > To summarize, for vIOMMU we can work with the spec owner to
> > define a proper interface to feedback such restriction into the guest
> > if necessary. For the kernel part, it's clear that IOMMU fd should
> > disallow two devices attached to a single [RID] or [RID, PASID] slot
> > in the first place.
> >
> > Then the next question is how to communicate such restriction
> > to the userspace. It sounds like a group, but different in concept.
> > An iommu group describes the minimal isolation boundary thus all
> > devices in the group can be only assigned to a single user. But this
> > case is opposite - the two mdevs (both support ENQCMD submission)
> > with the same parent have problem when assigned to a single VM
> > (in this case vPASID is vm-wide translated thus a same pPASID will be
> > used cross both mdevs) while they instead work pretty well when
> > assigned to different VMs (completely different vPASID spaces thus
> > different pPASIDs).
> >
> > One thought is to have vfio device driver deal with it. In this proposa=
l
> > it is the vfio device driver to define the PASID virtualization policy =
and
> > report it to userspace via VFIO_DEVICE_GET_INFO. The driver understands
> > the restriction thus could just hide the vPASID capability when the use=
r
> > calls GET_INFO on the 2nd mdev in above scenario. In this way the
> > user even doesn't need to know such restriction at all and both mdevs
> > can be assigned to a single VM w/o any problem.
> >
>=20
> The restriction only probably happens when two mdevs are assigned to one
> VM,
> how could the vfio device driver get to know this info to accurately hide
> the vPASID capability for the 2nd mdev when VFIO_DEVICE_GET_INFO?
> There is no
> need to do this in other cases.
>=20

I suppose the driver can detect it via whether two mdevs are opened by a
single process.

Thanks
Kevin