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+AIAEzMlAgAAJVQCAAErBwA==
Date:   Wed, 6 Apr 2022 05:58:50 +0000
Message-ID: <BN9PR11MB52764E3DE16E19D1F1515D008CE79@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>
 <BN9PR11MB527660D99D154F922B0A628B8CE79@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20220406012334.GZ2120790@nvidia.com>
In-Reply-To: <20220406012334.GZ2120790@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?zu6cmCGIZRoZI9T++uUPOR4aGOAPA5P4UF13TK3WzeJnaQRwtwisPDPosB10?=
 =?us-ascii?Q?PKHitjfjUrUi4R01B8dgktQYyTFL8h2Zye4B2CRz+p5HWKnZmeNVLjPlzp0F?=
 =?us-ascii?Q?KlpkcFGPn5LOVOJJO+bfU/gm32yIMS8XXiFQR3VRlv1eaFInw4gWL5xQdYGH?=
 =?us-ascii?Q?i48fSNXOneXowvhGJa2IGE3DkNC5sQeRnFeHo+skfJ5DzRtRCV9y3zgVXqNB?=
 =?us-ascii?Q?fbwcmz9xJI/1ZLYQcYoPorh7xHcruYtugI9wDceqMPsa45DkMSaav+QFXgo5?=
 =?us-ascii?Q?+Fwls8i4NevqHdpcNEwcTCS5xsG8U56+tah6y9xRHddKu08Nu96SLkUw7E3N?=
 =?us-ascii?Q?SsXDhQjndHc6ngcXLw+gltRZwNwUu9nE0LmriXbSeJKPnHecYiHQbEmd9zwL?=
 =?us-ascii?Q?yWK1WrRnRYC+AVvpCdvRM+NrRX9RNg21dJmgnOVMfH5da8C9UQ4Pnwi2dxqd?=
 =?us-ascii?Q?cS8lRQCeJEpiWcgUJ6a5y6T7ek9J0/9SR4ZKdwleesH9RVHRvD+Ekyf5/YkU?=
 =?us-ascii?Q?sX2DChbKKcipp6iQqmxaJBspbD3jj9LUWCraWKMsFJ0Tw17znTf8m/Hk0C5A?=
 =?us-ascii?Q?hI7v4cxwZrNEoDdWYMnoTmDvNUUXMxhXNKLLecHRFeXoUvmZ13bEf3i3vMb3?=
 =?us-ascii?Q?fGk29SX/3f0ta5cdrvFV30xhhciJlre0urT8vp0P1MeiJW5sPHBwMc9Ss/YC?=
 =?us-ascii?Q?/5y8fUabSuGAWiAbAEmpdB9V9G5lUThY1oFpd7oc9y9X/PjpAsiU0DvHEPsQ?=
 =?us-ascii?Q?vuunKfqQvO2VvlCKBA63fTXnebDNF8fsM1U9s0oHN4ZSa84zEKJMBWOOSKvH?=
 =?us-ascii?Q?opoWjabS6XfwJL3MXlrI1SxmdWC6/AQWJMgXnLKKFdDSFMkeZNJyasem6Xa4?=
 =?us-ascii?Q?IWAAKpf6AYxrCn/+fjmKLwGHntHWPqPVoA7yQyPCw1nhRrW/1yCzik4NpJCD?=
 =?us-ascii?Q?b+NDezeopBH2ENrwpePXCOws27WtsleDZXeA6TaDwPMvW62fmquvvKZzHQ0M?=
 =?us-ascii?Q?XUUCjrPW7e6LEuI32WsQx8oYiRutIhW5lvjaESPQDw9E03V69fT37vi9q5Go?=
 =?us-ascii?Q?Wu8e2y6xsoucIrm0j1qTgRfGEu0EDYGdE+cFYnd5PgzsC3s0ZY0nEy5IZjN9?=
 =?us-ascii?Q?M1W1WeGk/VBNRPNF8aUYJ3YbP/CMpyFWYpzrsu5VhOZT3pKdHF7ebfszyRLZ?=
 =?us-ascii?Q?KGe3tMOGBu02K6KLip4hEYFPB+nVn5Fqkd7OmGvsoUH0LjXEf0rhL9eWym+K?=
 =?us-ascii?Q?EVmvZ6lnkpuVvIwfXQfdTD4VjkUk1/iFXHBSErQI4f914hbsG+YxRYDADZ5e?=
 =?us-ascii?Q?yBKe22p5KkJeswH+v5EZa2rn0wI833IwljT6ZXluqfHbHlYNq1e+w2AlGEV8?=
 =?us-ascii?Q?2BBldPK5qDCPLdJhvCwlUxDkd5hCN7VraDx3ExXRb0OxLLeID+2xyDwu+anD?=
 =?us-ascii?Q?6RZsWzbtdA8Y3a90hUK9PTW/mE3YyejAx6+igOGBZrL4N8Ojue1v+zmN+isI?=
 =?us-ascii?Q?qqLsGrOyCMIDFfC2MjXJGwnQd9/RrtvSkKtb2/r+thTnB0BcSuH3cr9L9CYo?=
 =?us-ascii?Q?SpqZcm2nCY88/PWajiUD/Eqwg5iNnIMe1BzV75g+K1tmBYqQtVGXgV9TfxvT?=
 =?us-ascii?Q?0MM/BxdDfldaSK6cST1cBG+Bm6KhkVNDTlNkQ/oZ8OJCF8+7OCXG1AtXmKpf?=
 =?us-ascii?Q?XqSXkTLEK60cxJMDabgIsXzPtUvEv+7AGCnAB7LRWNK/lsJnK2N9b6QohmkY?=
 =?us-ascii?Q?GpjSRM8m2w=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: a49b06ad-1f72-49dd-b617-08da1792860f
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2022 05:58:50.7249
 (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: cAlpzy0jFHEo4mmOuM35km6O0vZisIEJZhdWHFa5hjo/S2cNWZopUz3cP9MgSsTTUXepPBt4Xdbllq4eKOXUOA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4497
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: Wednesday, April 6, 2022 9:24 AM
>=20
> On Wed, Apr 06, 2022 at 01:00:13AM +0000, Tian, Kevin wrote:
>=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
> Look at arm_smmu_attach_dev() - the domain has exactly one smmu
> pointer which contains the base address for the SMMU IP block. If the
> domain doesn't match the smmu pointer from the struct device it won't
> allow attaching.
>=20
> I know of ARM SOCs with many copies of the SMMU IP block.
>=20
> So at least with current drivers ARM seems to have this limitation.
>=20

I saw that code, but before this series it is used only for stage-2 instead
of SVA. and I didn't see similar check in the old sva related paths (though
it doesn't use domain):

arm_smmu_master_sva_enable_iopf()
arm_smmu_master_enable_sva{}
__arm_smmu_sva_bind()

If I didn't overlook some trick hiding in the call chain of those functions=
,
is there a bug in the existing SMMU sva logic or is it conceptually correct
to not have such check for SVA?

If the former then yes we have to take SMMU IP block into consideration
thus could have multiple domains per CPU page table. If the latter then
this is not a valid example for that configuration.

Which one is correct?

Thanks
Kevin