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:     Jason Gunthorpe <jgg@nvidia.com>
CC:     "Raj, Ashok" <ashok.raj@intel.com>,
        Shenming Lu <lushenming@huawei.com>,
        "Alex Williamson (alex.williamson@redhat.com)" 
        <alex.williamson@redhat.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.org>,
        David Gibson <david@gibson.dropbear.id.au>,
        Jason Wang <jasowang@redhat.com>,
        "parav@mellanox.com" <parav@mellanox.com>,
        "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Joerg Roedel <joro@8bytes.org>,
        Eric Auger <eric.auger@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>,
        "Liu, Yi L" <yi.l.liu@intel.com>, "Wu, Hao" <hao.wu@intel.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        Jacob Pan <jacob.jun.pan@linux.intel.com>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        Robin Murphy <robin.murphy@arm.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        David Woodhouse <dwmw2@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        "wanghaibin.wang@huawei.com" <wanghaibin.wang@huawei.com>
Subject: RE: [RFC v2] /dev/iommu uAPI proposal
Thread-Topic: [RFC v2] /dev/iommu uAPI proposal
Thread-Index: Add0lrMH87IsTsl5Rp6WN1oQU6kGMQEkayMAAADgu8AABbP/AAAAaVlQAAzVHYAAAm93gAAC/CGAAAII8oAAAftjAAABDbYAAAAstAAAAGyhgAAARNiAAAwRJHAAJs+EAADX6NpQ
Date:   Wed, 21 Jul 2021 02:11:12 +0000
Message-ID: <BN9PR11MB5433D6313D75EA10919ABE818CE39@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <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>
 <20210716183014.GN543781@nvidia.com>
In-Reply-To: <20210716183014.GN543781@nvidia.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?y7UW06f1UD9uyQKRiKcBy+uW71TItoagjQON8wpsfOUR0RbKmXg+IMVfzgQ6?=
 =?us-ascii?Q?MskVmyYlb1R7Cq5EIiUKQy5RDx1NPi6J55NFNomEbauO534iaWNZP4jXdf4e?=
 =?us-ascii?Q?+cWwYTcMlOfd9GbKj+MPVqFeSCxQvR6YU52hzdLQZlgi4FrlCJN6iP2PRtF7?=
 =?us-ascii?Q?CsWbkkHyJYQy0ZLOdezBO1AhCq2GJOM0qWwB8Vv2O/2d27cbtDa09eNj95rH?=
 =?us-ascii?Q?wdYEWTF4vLW4fP+x51J5OSuBhRHfwhBbuvio7Am6S3p29XKY8mHb5JpE72zH?=
 =?us-ascii?Q?XWGsMlVDyUzprvq+DlHJBLgSZ/qJxoJ27xjDU+Pzlo/y3ARrg+EccqsfeXsq?=
 =?us-ascii?Q?3kNztBAgd7nreZydR2sx/CX4248LwpjLTGWztQyFDMPAMzcgSvcgFZlGRwK7?=
 =?us-ascii?Q?vfFhiTcD8IVm2IQYoC8arCe8cicPFYFnqKqlY0KJuDRMXYbClu2d7sUkPGrM?=
 =?us-ascii?Q?n9tCMH6rWb6xj5DizHg4/52jmQNHZ4CW+O1mkDG/lJpMlBPdRZW1ufAfcr8r?=
 =?us-ascii?Q?kdfh37/srSSXioK4bJJy5Xw+ES5mtrcI7BVbgTuALcW6je2KvMoxq1tjK/fJ?=
 =?us-ascii?Q?Fvvgputd8fHYLvuYm34tfIHLhqJeI243W7sU2ZCgNsvxZq+W+klo4iOInA6I?=
 =?us-ascii?Q?ae8as+MhHpezVRmzH3Fx6NJ1qI6IQsLaTidSW00/aBREPRQ5J0B83S5qlHW4?=
 =?us-ascii?Q?PTRNVBpbiXvpDJ4JJjl1ZjGYqDg16OKqdupieah9/QrFhwX69e0HrpfcnQaj?=
 =?us-ascii?Q?NM5cCxJprV2qfRWyxao4YtBdIb59eZOVEgXVIoLL37sjkLtfxNAcb29Gs1So?=
 =?us-ascii?Q?ZUuhiKPAByRP2IRYUH8z7qRYZ17PlBQuMSrFkD6id+Gza231CEnPyp41mWdr?=
 =?us-ascii?Q?VAj2BqTflV9I8r/CJKo5c5r6WzMwn5OcU3TQ2c4X0yd8DhKVypEisha8Sp1K?=
 =?us-ascii?Q?PdwZ3+qbhkwYWzLZYdjK+nQXPbBBt+BOqPiicYGJzgzDzWXqZ5JsvPpJu5fq?=
 =?us-ascii?Q?9qkOWf+SKGdYTCQpkpHaWTm3sPr5Giy5KqLAlU/KslMv6F11KRkiby6DUVI6?=
 =?us-ascii?Q?kmK2sWUBQ7RgZ05dsYP80rZbtoNJX4KL+m7DV1vhfhy8qO2a0x9VDWtPywFI?=
 =?us-ascii?Q?o+3JNlCvib5aQy+MrRVLYjR+oH4sNtbdD08rtEGbzm/t7PsCBy/6mhZWZmB9?=
 =?us-ascii?Q?QYsCpyGuRoBfpN2BDWhF8v6R5+7jydrzRJ0s2qNwghR0MHG80Dmgsg5cLcr+?=
 =?us-ascii?Q?yG7fxJEBFr+5qKkzE09ULX+trymlXedO5c1AW+KzwoOnftbO+LnJTRrAu4Bo?=
 =?us-ascii?Q?cSNPJKa2yFXm8Afoz5DOXR9c?=
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: 450aeac6-cd2b-48c5-67de-08d94becd03f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2021 02:11:12.5537
 (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: wUIWWoWo3hhNmolLYuUk/W/l/Son5pNorEVtGmIyYh+8Ma0yWz3Gl8IKLu9nf30p8a9vZ3WUzMaRY2QXI58JoA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR11MB5758
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: Saturday, July 17, 2021 2:30 AM
>=20
> On Fri, Jul 16, 2021 at 01:20:15AM +0000, Tian, Kevin wrote:
>=20
> > 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
> I think it makes more sense to expose some kind of "pasid group" to
> qemu that identifies that each PASID must be unique across the
> group. For vIOMMUs that are doing funky things with the RID This means
> a single PASID group must not be exposed as two RIDs to the guest.
>=20

It's an interesting idea. Some aspects are still unclear to me now=20
e.g. how to describe such restriction in a way that it's applied only
to a single user owning the group (not the case when assigned to
different users), whether it can be generalized cross subsystems
(vPASID being a vfio-managed resource), etc. Let's refine it when=20
working on the actual implementation.=20

> If the kernel blocks it then it can never be fixed by updating the
> vIOMMU design.
>=20

But the mdev driver can choose to do so. Should we prevent it?

btw just be curious whether you have got a chance to have a full=20
review on v2. I wonder when might be a good time to discuss=20
the execution plan following this proposal, if no major open remains...

Thanks
Kevin