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: lAgdX8uCg0jmp28yLpsbvraZlpOzJORavagsJWRA9HZSvmszTtf3PyroyHOEA97LMSR/Sx6bQ+
 nd+3hwbWc8rQ==
IronPort-SDR: r6q58A77THS/j1sCQIcEX1WdtyP1sRYAPFmX+4cE7ToAIknvvCNgxg/M66SlIOvIWylltGZuMZ
 S3V3y7Zy8+fQ==
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     David Gibson <david@gibson.dropbear.id.au>,
        Jason Gunthorpe <jgg@nvidia.com>
CC:     Alex Williamson <alex.williamson@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Joerg Roedel <joro@8bytes.org>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        David Woodhouse <dwmw2@infradead.org>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        Jason Wang <jasowang@redhat.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>,
        Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        Robin Murphy <robin.murphy@arm.com>
Subject: RE: [RFC] /dev/ioasid uAPI proposal
Thread-Topic: [RFC] /dev/ioasid uAPI proposal
Thread-Index: AddSzQ97BhCb3gd8AUyldaDZ6yOMNABL2ymAAKTbxpAAKSt7gAE2pF4AABZhzAABsLRAAAE2elIQ
Date:   Wed, 23 Jun 2021 07:59:21 +0000
Message-ID: <MWHPR11MB188626BD4B67FB00EFD008ED8C089@MWHPR11MB1886.namprd11.prod.outlook.com>
References: <MWHPR11MB1886422D4839B372C6AB245F8C239@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210528200311.GP1002214@nvidia.com>
 <MWHPR11MB188685D57653827B566BF9B38C3E9@MWHPR11MB1886.namprd11.prod.outlook.com>
 <20210601162225.259923bc.alex.williamson@redhat.com> <YL7X0FKj+r6lIHQZ@yekko>
 <20210608131756.GF1002214@nvidia.com> <YMrF2BV0goTIPbrN@yekko>
In-Reply-To: <YMrF2BV0goTIPbrN@yekko>
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?8+/otyL3RTye9/4qCqB2jMiNjbZeKr8MznAiJKDTRMqcdSsX8Q9fCiaxxzu6?=
 =?us-ascii?Q?ABeVHQFh+ij8zyaN0P398mpnYEw3+I7W/HLOXA2mMBA+aOBvg/mfZyBJJOIC?=
 =?us-ascii?Q?3TR+Odhj4V/OGsXitGy3xIf+VtXzz07f+ajFM0mvFXGsDQs7I5yLzr1bzb6w?=
 =?us-ascii?Q?VmJCV9SGZctvEu6medN6hSKOKn0BFbKiR57PTd+TzLTRWBmWA7O9eJIWA7MN?=
 =?us-ascii?Q?CyUn0Y2mk7vS7pa2clyEJlLd83v1hFsS1HnXRXyoO6ea8tIx7OtqAepSfK3k?=
 =?us-ascii?Q?zOc9BUQuYjEl8//xIUn0dk7GvHCtzZXwLWro22UuofLg5ZwdfJL2OZ0PbiGW?=
 =?us-ascii?Q?UaJuUbP9H9AgTJV2RvjJAH2SHTnKKeZbv/z0LBq2HTM5Q03aJe5M4OSVrRV3?=
 =?us-ascii?Q?BZtKemCAtxkOw4JE5tyP3GYpoHuS6q+DfoOtlNi7V9RnjfUHhm30QYWUwwfi?=
 =?us-ascii?Q?BWdSCoW5lBbcl479funUsr+vOmTMb3ZJO631a9NY27U5zEHRC+Sj0enyXizS?=
 =?us-ascii?Q?iP7WZ/DQRGaLFG+NIX351Fzy5TMCWIirWDCNB5sfqlTYshO3CtXLG6CS9yE6?=
 =?us-ascii?Q?w4L79uqmLwkM9x59wMgIt42qx2ZfQIlEH1fkxpakWwzWoJ4mQ4hiUyOPjJ1N?=
 =?us-ascii?Q?pwd6O0nCObyvcph/o4BULgBWRJYna+jFdLmlqqLe79qh2LFyLuUw8GcDxWc7?=
 =?us-ascii?Q?ccQBdQ03YWuV4zOozHYouL76cAdRjKvGexXaRZ9ygYoQaPNLoqOZHRcqx6g4?=
 =?us-ascii?Q?mcpU9yiEHGAKIfzknOfihpKsFt3zGQpUn0hVxJZZ6VM4gWFWx4vlrOYd0If+?=
 =?us-ascii?Q?UkiyOlNHe5P6s0Cl9x78nfD43dHA7iw4DBXbu3JMaF+Cba86JL6y06LTSXWg?=
 =?us-ascii?Q?ueKt6lL5R4RQbsPzxM3t1JtOPsoV6t2WgF7kzH9R7jNdLEh4cM0kYGpq2cOv?=
 =?us-ascii?Q?3x6UF0f4mh7v4LbxIzdZUPbY6CuIEs2pI4MXDWYSf7V+5F6wHyDq5amcAvKd?=
 =?us-ascii?Q?110878/eJ22VUIUJUHQsf2fqfElFQfvrTkeXDCu0W/HY+BdifX0MX8F540Aj?=
 =?us-ascii?Q?i/lecOwkXfJEXvmYJtb+utpBXa4Vj1v18A3PCDaNan5Dc30TiGiEJ/fQh7SM?=
 =?us-ascii?Q?fiDR6IYVbsmcGhmdQ02w/XHQElG/476hRDj9RRZP7inQTFIt9WwfHRdqLGJL?=
 =?us-ascii?Q?oOKB/qrOSUEEyZuetkgzRK4kXQcGz+n63KzhpMng3mfJRmgtsGDpL1REqfqR?=
 =?us-ascii?Q?u7SuomuEtkTcvdTWrsdnas8i1ZMl4QY6GFvvMGzpKjF2fpoZ+pkG4KG+wgzS?=
 =?us-ascii?Q?FiyhT6V8m5mU4FnpbOhIGuu6?=
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: 3f419dad-3974-4e44-8fc8-08d9361ccf51
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2021 07:59:21.2440
 (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: eWByGb40t9+OHZ1oYpuYYKFKc5H2hbmNpO6ReE3RJT9BNh/hYd1OpIBGbYcDAumr8o9nlGeDB60DgfX5vLwRvA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1933
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: David Gibson <david@gibson.dropbear.id.au>
> Sent: Thursday, June 17, 2021 11:48 AM
>=20
> On Tue, Jun 08, 2021 at 10:17:56AM -0300, Jason Gunthorpe wrote:
> > On Tue, Jun 08, 2021 at 12:37:04PM +1000, David Gibson wrote:
> >
> > > > The PPC/SPAPR support allows KVM to associate a vfio group to an
> IOMMU
> > > > page table so that it can handle iotlb programming from pre-registe=
red
> > > > memory without trapping out to userspace.
> > >
> > > To clarify that's a guest side logical vIOMMU page table which is
> > > partially managed by KVM.  This is an optimization - things can work
> > > without it, but it means guest iomap/unmap becomes a hot path because
> > > each map/unmap hypercall has to go
> > > 	guest -> KVM -> qemu -> VFIO
> > >
> > > So there are multiple context transitions.
> >
> > Isn't this overhead true of many of the vIOMMUs?
>=20
> Yes, but historically it bit much harder on POWER for a couple of reasons=
:
>=20
> 1) POWER guests *always* have a vIOMMU - the platform has no concept
>    of passthrough mode.  We therefore had a vIOMMU implementation some
>    time before the AMD or Intel IOMMUs were implemented as vIOMMUs in
>    qemu.
>=20
> 2) At the time we were implementing this the supported IOVA window for
>    the paravirtualized IOMMU was pretty small (1G, I think) making
>    vIOMMU maps and unmaps a pretty common operation.
>=20
> > Can the fast path be
> > generalized?
>=20
> Not really.  This is a paravirtualized guest IOMMU, so it's a platform
> specific group of hypercalls that's being interpreted by KVM and
> passed through to the IOMMU side using essentially the same backend
> that that the userspace implementation would eventually get to after a
> bunch more context switches.
>=20

Can virtio-iommu work on PPC? iirc Jean has a plan to implement
a vhost-iommu which is supposed to implement the similar in-kernel
acceleration...

Thanks
Kevin