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:     "Alex Williamson (alex.williamson@redhat.com)" 
        <alex.williamson@redhat.com>, 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/ocAAK16TAAAGdqAAACJdiVAAA3a7AAEa314AAD0+zwAAe3StQA==
Date:   Mon, 28 Jun 2021 02:03:56 +0000
Message-ID: <BN9PR11MB5433DCBE6DE1EC27CFB9D3738C039@BN9PR11MB5433.namprd11.prod.outlook.com>
References: <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>
 <MWHPR11MB1886A17124605251DF394E888C0D9@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210618182306.GI1002214@nvidia.com>
 <BN9PR11MB5433B9C0577CF0BD8EFCC9BC8C069@BN9PR11MB5433.namprd11.prod.outlook.com>
 <20210625143616.GT2371267@nvidia.com>
In-Reply-To: <20210625143616.GT2371267@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?qeWzP62y/LPxvMRk3yys6in5trc5jES+kv1R4SXStHddtkRCVJA5V6LQS4oT?=
 =?us-ascii?Q?cf6/hMBY7Q5PH8S9dTY3EmLt5gpTVgSzOeRZyP0bvxM5zmRKap2YLslrDdBy?=
 =?us-ascii?Q?DSKXX+qh8ctdlGRDDjRu1cIbnK+uRf96zMWQ5ZzZIpFZIZw6etGk4Wy2jhuM?=
 =?us-ascii?Q?KVIsXOXiPmCjrJwrD3bCQj6rn841SZf3QsUgSnSu04EMLPcpfjyhrfKp7LHr?=
 =?us-ascii?Q?33pyl0hORmLDcp3syS1Dj8WyIXvZhS37QgDDhqiAF6/aInzoLcSdFr3U5ImX?=
 =?us-ascii?Q?bWvUAgHTMy+Nse3yCSWyAW1VI7lnEUhuDehGwoNAb/CuA3eG69o91nD18OOZ?=
 =?us-ascii?Q?+M8O9DysB60fLW13aOUkJUVdVvsEiiI9suwpPR/yXuRKNP57I8IwqUgCt1eJ?=
 =?us-ascii?Q?Jp7ry2X/qDi6ncT1judFgxQPMABUDESSqA+9Wtp8OT4hIuKiEMoGXggSSRRO?=
 =?us-ascii?Q?+kAoTbAbsZ2KUSVmoXTfbKNCP0Vw8ozzwSMOHSYJU70XCChbgLAHuDCyMKKL?=
 =?us-ascii?Q?M4FMZN14YzaoVYhtS22FQ1KQaLHZdno28sqM8CGTPlmIMD2K54KsAt1AKX3j?=
 =?us-ascii?Q?0i5+JgpqAaasdHH7ltJUb3JM27ktZ6QOlopyU+y+der9MmqyLlF5KUt2j2J1?=
 =?us-ascii?Q?Bu7dFy8pVzqi/XFf7LZrIsrcMC1POcMafxarBb4AnkMQUOWxif48k8ZQIniT?=
 =?us-ascii?Q?cFMkQvghdx9IkW3h78lIFcJPUaezyt7TWOoLoHSMLEHX+5w4EIKDRBRK8WU4?=
 =?us-ascii?Q?MdR4ANpQQTGHNYHQwiMgBXfLqPct4EwWyTS4BPa/Bjhwpo4Xxx0kiQRRb058?=
 =?us-ascii?Q?FBGk4Y241XBvG3E+YkixMA1TPxSF0lda4DbhLW6e1dk/G7ZFRAegYexPjd8b?=
 =?us-ascii?Q?+iclUHXSu+zF5oJNlPox/suf/ngzxoTtofSkkQSkEd/oMDnCmhCoVjzeHkvi?=
 =?us-ascii?Q?4UxrE4AD65ITRm0ZkzJs3O0VXe/Ssj1aYlVUJ7InsTwI2HAsmRIcI3fTpNW2?=
 =?us-ascii?Q?VrljzCcz+mDV7VnxGomKTW6VJJTAAJV9Gh3/LfcdWneb4mVwjSa2PUivLlF0?=
 =?us-ascii?Q?C919PDzxaw8jGI8AodixgInVrSgpIS7vnXgCKLL+9OgTpTDf98Ljg+Durv1k?=
 =?us-ascii?Q?zZS0JL+ICJmkgqsX9bxdR5ZEXtY225RUQhrquLwcHc+IrHbOwQCxihCki3tD?=
 =?us-ascii?Q?rxHbHtXWJo0URgjbMnFfKQ3S9Ab7qr5133g3P+tKUh+EfYAMxEYH7bSe5hh0?=
 =?us-ascii?Q?t3mfRr8SemZF7YgmupaWUi3TBYGQyCtE1gR4XArzTssIklMewgXIBFyD4fX4?=
 =?us-ascii?Q?IHOJl7ub5jylGszwnGJBPq3B?=
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: d13a04cc-feee-421a-1b75-08d939d8fcc2
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2021 02:03:56.5048
 (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: hZbQiVDbgpZYTULSuTJnvgHhfsyMyszKMrmmEjDCg09lqR1q+MpQzzS2c5Qeewe4axvtPOm/kGMbS54JiT26WQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5532
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi, Jason,

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, June 25, 2021 10:36 PM
>=20
> The only thing that needs to be done to get the 1:1 step is to broadly
> define how the other two cases will work so we don't get into trouble
> and set some way to exclude the problematic cases from even getting to
> iommu_fd in the first place.
>=20
> For instance if we go ahead and create /dev/vfio/device nodes we could
> do this only if the group was 1:1, otherwise the group cdev has to be
> used, along with its API.
>=20

I may misunderstand your position in last reply.

The bottom line is that iommu fd uAPI and helper functions should be
device-centric (no group fd carried). This is what this sketch tries to=20
achieve.

However I'm getting confused on your position on vfio uAPIs.=20

At some point I feel you are OK to keep vfio group fd:

    "For others, I don't think this is *strictly* necessary, we can
     probably still get to the device_fd using the group_fd and fit in
     /dev/ioasid. It does make the rest of this more readable though."
https://lore.kernel.org/linux-iommu/PH0PR12MB54811863B392C644E5365446DC3E9@=
PH0PR12MB5481.namprd12.prod.outlook.com/T/#m1b1d2b4d6413e3b32ba972a97c2c6a1=
6bf491796

But you are also obviously against faking group for mdev.=20

Combining with the last paragraph above, are you actually suggesting=20
that 1:1 group (including mdev) should use a new device-centric vfio=20
uAPI (without group fd) while existing group-centric vfio uAPI is only=20
kept for 1:N group (with slight semantics change in my sketch to match=20
device-centric iommu fd API)?

If yes, some assumptions in this sketch might be changed. For example,
with /dev/vfio/device node I'm not sure how the user can pass {iommu_fd,
device_cookie} to establish the security context when opening the node=20
(not via an indirect group ioctl). Then it implies that we may have to allo=
w=20
the user open a device before it is put into a security context, thus the=20
safe guard may have to be enabled on mmap() for 1:1 group. This is a
different sequence from the existing group-centric model.

Anyway, appreciate if you can elaborate your thoughts so we can further
think about them.=20

Thanks
Kevin