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;
IronPort-SDR: Yd/HEHPDQPwH/Tfyw7G8HCM+KdaqsUuI4NFL+44AJzwJcfPQ02bwaddh7yEV+jXryWvnM+s/x9
 BWzDOacJ0QTQ==
IronPort-SDR: S4xW0ZOBDK3iqCbhFoctWjFaGcRZUlpMgbeXbr7XKLKS/mIu4815FG8Qj8JkW/0+Xhus46NOpr
 KmRkVXGWWT2Q==
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>,
        Alex Williamson <alex.williamson@redhat.com>
CC:     Joerg Roedel <joro@8bytes.org>,
        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>,
        Shenming Lu <lushenming@huawei.com>,
        Eric Auger <eric.auger@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "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>
Subject: RE: Plan for /dev/ioasid RFC v2
Thread-Topic: Plan for /dev/ioasid RFC v2
Thread-Index: AddbO/WEUAFl3MPnRsG8exiH8bwEagB7l+uAAACIfoAAAdwYAAADDw6AAAHKgwAAANd4AAAAacwAAAT4QwAAK587AAA0n7GAAAYKlwAADDvuAAAgbLGAAF6lSYAABO0WAAATSRtQAB5ymYAAEyKHQAAmZhSAAAo/ocAAK16TAAAGdqAAACJdiVA=
Date:   Fri, 18 Jun 2021 16:57:40 +0000
Message-ID: <MWHPR11MB1886A17124605251DF394E888C0D9@MWHPR11MB1886.namprd11.prod.outlook.com>
References: <20210612012846.GC1002214@nvidia.com>
 <20210612105711.7ac68c83.alex.williamson@redhat.com>
 <20210614140711.GI1002214@nvidia.com>
 <20210614102814.43ada8df.alex.williamson@redhat.com>
 <MWHPR11MB1886239C82D6B66A732830B88C309@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210615101215.4ba67c86.alex.williamson@redhat.com>
 <MWHPR11MB188692A6182B1292FADB3BDB8C0F9@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210616133937.59050e1a.alex.williamson@redhat.com>
 <MWHPR11MB18865DF9C50F295820D038798C0E9@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210617151452.08beadae.alex.williamson@redhat.com>
 <20210618001956.GA1987166@nvidia.com>
In-Reply-To: <20210618001956.GA1987166@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?EDnJRwnxBBD5n9jfO3P98kfqqB2t7xkd/E4XNNfKcQUOblyfXlWPCe99P30S?=
 =?us-ascii?Q?wRg1tX/EawREgNXRVAmv6LycdACZf4RKYABVWTW76qJ1gEaqtbrcDTN/WiaZ?=
 =?us-ascii?Q?gVi7AlNU7GOzB7HbBKFIIoehHE8IZSeEqmX7NpYTEepbgQ2rA0Ht/qKz8EYX?=
 =?us-ascii?Q?y7bE9FKqukG5kQ7lEuCBp601PlSFGPvzx/kp632kuoOUE3l0LapoRAqIIxK7?=
 =?us-ascii?Q?R6O0IN4ja3E7UV1ZeB3P6bJbzxW7urAdT35SUP28f9TKOBTZ4801dNrkEj1P?=
 =?us-ascii?Q?sc9aVu1y8w/lus5zVpmVZq5oO6k2k5qvl7QoQWZdmLmLHyu6246zcm8Aea/i?=
 =?us-ascii?Q?3MPqzghiA8+qKy3pq7tx3bsydmioL8SgZHvI+yExL5yFyO4bLMuVBnz33u/W?=
 =?us-ascii?Q?oaXqFhVO/wbXkSDK4Xw/2hiAwaBDssyVcCwSjZYSENKWr7AC9TOscIAiWD9M?=
 =?us-ascii?Q?Z70KHaTDNl21ZzZyd4hWC0rwKA+ixbUbJ19ZkIxA2LhO3mRYFTShL2Axq1o+?=
 =?us-ascii?Q?rhwaPuOh6brxxCNY2GDUWn41CplP9b57jHOdS9IzEkE6+6XDM35eeFKldABn?=
 =?us-ascii?Q?OLWHxHkDXAxDcisNWg8rotFfWhg6FlpvO5b/k6oX+TRXVQDE1vMyko9vH4L9?=
 =?us-ascii?Q?B2lqtq9r0HeikAemoADJuR7UM2QvyP21njGawnOciHhVXagrhz7AmvVkBG8d?=
 =?us-ascii?Q?NTs9nCxQfURZO81lcL+6bhjawsMIVapIswokD0eUprdZH9IlX/5gAWU9xsCz?=
 =?us-ascii?Q?Iy1k5S1wFK2Q9TuR50AnlV66aRMpGic+Mn2fxyqxj2kahRBVsppAUHoGWXpK?=
 =?us-ascii?Q?Gvm/fTnNWKNl0wIW4nA2TfLerILzHPEk00iYIqEW5SaCAfXSeilP2iY+cfTQ?=
 =?us-ascii?Q?bT/YWkH+aPdGYx/gfD27r9DkGbGdGcyyp7QyzTdv01wnahxbRJwgi6/YoCnv?=
 =?us-ascii?Q?z5tzN5gmwGTVHIvEAW71fVt2q7NfipXMTCwGApVtAxYN7vHKkXQW/7YJE7Ad?=
 =?us-ascii?Q?JwmMu3sXkfeuvc/NRroxWGPi1xRq7K3uHOJ3pzGIrY1czsPqCRxFGdeTBww6?=
 =?us-ascii?Q?cCHocy7e/L9IKXXcWZ1FMGmsfmCIDpXLhBzx3KsIeqyoNreODn333g0oL0ZX?=
 =?us-ascii?Q?ocD1r0gRrN7y9z1/qiKoDsFjFFEo5ix6ldp8Hs72uOzfLNHsHm2+upbYl/LU?=
 =?us-ascii?Q?QHTcDZ7F9udPzmPmDCM0b4iIyRwVqw1Tk0FQ+ZJiVacUCu6VEOhVvR2Iaeys?=
 =?us-ascii?Q?K/9QUFFf6zUeu0AU2MUccLGh2yrJMoW50soBHHl02WdkgevUK0iwF5kUIMLb?=
 =?us-ascii?Q?kamCKB4jH//IgZx0r3coiXEH?=
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: MWHPR11MB1886.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 507a175a-4a08-444f-8071-08d9327a2f20
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2021 16:57:40.5994
 (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: LyqFdgzAzbWAZaridupLavRE/CC07D4l4Qr1hX7TA6RtUjm++221JPaqxOIHEh4MppMXJzwUFlUL7aUXKvE6rw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4996
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, June 18, 2021 8:20 AM
>=20
> On Thu, Jun 17, 2021 at 03:14:52PM -0600, Alex Williamson wrote:
>=20
> > I've referred to this as a limitation of type1, that we can't put
> > devices within the same group into different address spaces, such as
> > behind separate vRoot-Ports in a vIOMMU config, but really, who cares?
> > As isolation support improves we see fewer multi-device groups, this
> > scenario becomes the exception.  Buy better hardware to use the devices
> > independently.
>=20
> This is basically my thinking too, but my conclusion is that we should
> not continue to make groups central to the API.
>=20
> As I've explained to David this is actually causing functional
> problems and mess - and I don't see a clean way to keep groups central
> but still have the device in control of what is happening. We need
> this device <-> iommu connection to be direct to robustly model all
> the things that are in the RFC.
>=20
> To keep groups central someone needs to sketch out how to solve
> today's mdev SW page table and mdev PASID issues in a clean
> way. Device centric is my suggestion on how to make it clean, but I
> haven't heard an alternative??
>=20
> So, I view the purpose of this discussion to scope out what a
> device-centric world looks like and then if we can securely fit in the
> legacy non-isolated world on top of that clean future oriented
> API. Then decide if it is work worth doing or not.
>=20
> To my mind it looks like it is not so bad, granted not every detail is
> clear, and no code has be sketched, but I don't see a big scary
> blocker emerging. An extra ioctl or two, some special logic that
> activates for >1 device groups that looks a lot like VFIO's current
> logic..
>=20
> At some level I would be perfectly fine if we made the group FD part
> of the API for >1 device groups - except that complexifies every user
> space implementation to deal with that. It doesn't feel like a good
> trade off.
>=20

Would it be an acceptable tradeoff by leaving >1 device groups=20
supported only via legacy VFIO (which is anyway kept for backward=20
compatibility), if we think such scenario is being deprecated over=20
time (thus little value to add new features on it)? Then all new=20
sub-systems including vdpa and new vfio only support singleton=20
device group via /dev/iommu...

Thanks
Kevin