Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>
CC:     Lu Baolu <baolu.lu@linux.intel.com>,
        Joerg Roedel <joro@8bytes.org>,
        Christoph Hellwig <hch@infradead.org>,
        "Raj, Ashok" <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
        Robin Murphy <robin.murphy@arm.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.com>,
        Eric Auger <eric.auger@redhat.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "Pan, Jacob jun" <jacob.jun.pan@intel.com>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH RFC v2 03/11] iommu/sva: Add iommu_domain type for SVA
Thread-Topic: [PATCH RFC v2 03/11] iommu/sva: Add iommu_domain type for SVA
Thread-Index: AQHYQy+FIia0eWaSv0yH5HJtvKyQTazYSueAgAQE+8CAAP1+AIAEzMlA
Date:   Wed, 6 Apr 2022 01:00:13 +0000
Message-ID: <BN9PR11MB527660D99D154F922B0A628B8CE79@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20220329053800.3049561-1-baolu.lu@linux.intel.com>
 <20220329053800.3049561-4-baolu.lu@linux.intel.com>
 <20220330190201.GB2120790@nvidia.com>
 <BN9PR11MB5276A39F481E2E31B0FCFEAE8CE39@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20220402233210.GM2120790@nvidia.com>
In-Reply-To: <20220402233210.GM2120790@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?6rssYxJDj6PTdJGyuCdR1sqY4Sju1bXViNIqJZA/RXplaDkP7WRU4mwNAjk+?=
 =?us-ascii?Q?A5mkzKBbQxraRjHLyoBcojx7a4Dc4nnX+fsiKocIWyPjCLSHYPfmMzM7t2Di?=
 =?us-ascii?Q?srwo/qt8VnfPLbKf+veizJXVoQqyiNEFKsfRIBXedB4pH970UdAv/kfOmA6u?=
 =?us-ascii?Q?xnnpW+UBr1LrCD3oYoolXGx65Jt6IXDvF46vOKCpXN/9ZyANGQX3hYrKrHDr?=
 =?us-ascii?Q?I+bu2ArtTn3OyFDv4Afk3omxRz66aHCwCNr+0W9irrZOkKbDDeLSmpwffpyD?=
 =?us-ascii?Q?58hPGyB2z1iPUfm0KLY/uH7+NPP1BMNjevmyuQGaeQi0f/rDEV5WKW9TnuRq?=
 =?us-ascii?Q?R/TcTo2+QBHu7iBMUTAL2Y1tWJiCJJu3+ZR8YZ8gbvAT+YCvkcEiZSsidipC?=
 =?us-ascii?Q?Z1cZ6ROju8k9nAeWAsVbJILqLZFg8wV+iyzwKyGam7SmuM8Ea5n/K96t77Oq?=
 =?us-ascii?Q?FJOr2nUvQmZDSFWxeYA/RvyJvRE2e+ALWZrpCdOD299WGXpKOZBjHNYgHfQ6?=
 =?us-ascii?Q?AQRCe4TE8VYWb+Nw0UkQ+xQt1DhluvRdyL+rpcjPEyGI1CsR+LL4wjZaUtXa?=
 =?us-ascii?Q?v9X63Ba0h2Jg0yY0FMKeTX81mDmNwUWOSdEbAc4Q/pEAgHlj1VKRxylM4QEK?=
 =?us-ascii?Q?ghZ9aJpOi2I/oMF3TyhlbGMQ7RRrPVWxrcoQVuQJ5yMj7omoPuowgZ+Mpg7G?=
 =?us-ascii?Q?RGvfeJ3k6+yrWpsuQwhLIvNrd+mPbnv2uHjNuuVO9t7LcY3zqvuTPhTnY03R?=
 =?us-ascii?Q?PfsqB58u7ZP6pZZvlh5BciB93sVz8Lr8SWakjSX+dWHUwcCk6SlQQ4F8B/Q4?=
 =?us-ascii?Q?H/n2YcV0Q1EcSGiKJzRJT58IutkNtVaPkQvdxqGM1i9IvvUalVjKqXPEIk6R?=
 =?us-ascii?Q?HKvrPqteCiWhMDdDons4rlrKXkEtpjB3iawd4IyKqr5RX3mhAnmtWE+bf7OJ?=
 =?us-ascii?Q?qtab57NjBhqraWRdTHaasYDb80e+CNWP1WhGXnDPqVLa+7vxeD5pbUS4j3Q9?=
 =?us-ascii?Q?nGFMBlKplJe/3+SAHHPFgPkWSOeVb8rmmhmb7oOi8GzKYMIrJdDlZiYdnfSA?=
 =?us-ascii?Q?1XDjZoAWlWwEnMqALaPcXTmUF+EZplMATDiEpIMnzn4TB7wIIoejYY9C0oCM?=
 =?us-ascii?Q?hccaX1TKtbRL1qihaHkkahaEP2fQTRtgnEyb3ntery+/IGkryDF/fEbSyzrO?=
 =?us-ascii?Q?UWIAzN3OYkpojc5sAZrz2yqguBaQ1TDKPMuL++j3hpYXwGpi5YirPuFlp6I5?=
 =?us-ascii?Q?eOIMGGYB5NKHr6Px0LojFX/KRb3fpKpYgLX7vVGjTFyZnHqo3xSGHD+ldsGE?=
 =?us-ascii?Q?avQIbeXA5APqoh8Mvs1mCO7l3LP/O6/7SPS2t2VETRqM2rONomQu1iNhqHwN?=
 =?us-ascii?Q?CIMoqt1U5Wgu38CuwhHwXKsLkjSrMnGTho12hjjK8KaGff26UvMfU2V63gP8?=
 =?us-ascii?Q?GFxJWA/cy0dCVbfT8gNEPK8wmMfQW2N52W5iuBNQ7gR84BlzxvBT6T/dTS8U?=
 =?us-ascii?Q?7vBFGYrPV5xZA5xWsRSwSuQqUKndH8G+VOftwZFiUs51J1q1m2Hf5RxX8brp?=
 =?us-ascii?Q?HykWPjotH8J5yD8mxI9JXaQK3W6z4MvBDjpIMvUA9iQZKsCStINnxZLnH3vd?=
 =?us-ascii?Q?R5jiHLel6cgx1a/XjSlPSsl2rtEKndc7VPmjybnre3D93GF9N0vYrVst7Hu8?=
 =?us-ascii?Q?FrN1HxCt5BM9IFGOqBEjlSPzoZKg/fbgHQyjbo4gPmCKKO2C1oMbpni2On8r?=
 =?us-ascii?Q?ViTvDMyH8Q=3D=3D?=
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: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0445bdc1-4e38-4eb5-00b4-08da1768cea5
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2022 01:00:13.6835
 (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: PPKnfqWD2sEt0vBrpkVgo4OffuI7lWCDdBwOQdEfyqRtdPguAQ/viOvaIQGLl7OKh4H552IaDTG32+xgQx62/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3286
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Sunday, April 3, 2022 7:32 AM
>=20
> On Sat, Apr 02, 2022 at 08:43:16AM +0000, Tian, Kevin wrote:
>=20
> > > This assumes any domain is interchangeable with any device, which is
> > > not the iommu model. We need a domain op to check if a device is
> > > compatiable with the domain for vfio an iommufd, this should do the
> > > same.
> >
> > This suggests that mm_struct needs to include the format information
> > of the CPU page table so the format can be checked by the domain op?
>=20
> No, Linux does not support multiple formats for CPU page tables,
> AFAICT, and creating the SVA domain in the first place should check
> this.

One interesting usage is when virtio-iommu supports vSVA one day. At
that time there needs a way to know the format of the CPU page table
and then virtio-iommu driver needs to check whether it is compatible
with what the host iommu driver supports. But possibly this can wait to
be solved until that usage comes...

>=20
> > > It means each mm can have a list of domains associated with it and a
> > > new domain is auto-created if the device doesn't work with any of the
> > > existing domains.
> >
> > mm has only one page table and one format. If a device is incompatible
> > with an existing domain wrapping that page table, how come creating
> > another domain could make it compatible?
>=20
> Because domains wrap more than just the IOPTE format, they have
> additional data related to the IOMMU HW block itself. Imagine a SOC
> with two IOMMU HW blocks that can both process the CPU IOPTE format,
> but have different configuration.

Curious. Is it hypothesis or real? If real can you help give a concrete
example?

>=20
> So if device A users IOMMU A it needs an iommu_domain from driver A and
> same for another device B, even if both iommu_domains are thin
> wrappers around the same mm_struct.
>=20