From patchwork Mon Jul 24 10:59:34 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yi Liu X-Patchwork-Id: 124854 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9010:0:b0:3e4:2afc:c1 with SMTP id l16csp1732362vqg; Mon, 24 Jul 2023 04:29:46 -0700 (PDT) X-Google-Smtp-Source: APBJJlHA/T5q3Q3URdwBw9k57S9w8wVd2GcMvaXH9izLFgUo1/VT8tXg81hjQbYAL8aROPwg8913 X-Received: by 2002:a17:90b:3502:b0:263:d6a6:f37c with SMTP id ls2-20020a17090b350200b00263d6a6f37cmr9056336pjb.16.1690198186317; Mon, 24 Jul 2023 04:29:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690198186; cv=none; d=google.com; s=arc-20160816; b=0ZaXRjM94gLyQro6dekvIzyO9GiMMD36A+K6brsNbG28aUbCGrJdomPLMQqDTj2Y0V tXk8YCmIMKy57WU0zzGhEjjpTVbSDJ7MVDMMuPzAiNaYnsJmizNdkWsnw4znNw2qSo71 SahCiMUBFnVRwbLX78+Q8OwB4gcH7YWfCGk2CWPCJDJ/Jb3evkIcXLytF73cQK+BA2yW GpxvpeRbeiOCxpeIdZQKz/GQlXHIJwG15tehEbIPzXQ1Vw1kKnlLzQRwYTcdX7rfxnrI 2MiDlheYC2RL2twArM065iu4aDAi6qL54QV+MBHp/x4sX+XVwp11aeUVqUgZzmy1ChQ7 YWrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=6B9Tm2MFXvxzSWLdVfhHqlKT58ct5yf24W+n3fnettQ=; fh=25kVo4cotgMzE250R6E3K5ES7E7C2JawiavlW0h5mKU=; b=Yuz7+getubVz8CF8d3IfwSzUYUBo+PKo82pe+Q19NRC1H/2qxDa1DNhFbl/V6D7w0R MN5lbTt68v5u0w1jrk6egvwh5luDTqoz2PpLdqyGpXHuCjpWNEquIA9kylW8cTHWilSm /yfevZxUqhYSJXGWyV1hLmXa29OkY4R/DyHtMbDZt5ZOULOVKA8BVximCl/sYxof2Nh9 xqxRO/bGeaVD41u6NbW5aeHhFuLQsuqYwFl4GdmdGRYT4Aobgv4oipT9nxHrsX0FFAAT 1EmS0ud/Q/8iSLjeR+vUCi6RwIJAg2KzQxJ76O6RrWn3UD2pFgPtQ7nEOasYAqHCeTr3 8e1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W+7EJVTO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w64-20020a638243000000b00542d3727da9si9184803pgd.464.2023.07.24.04.29.34; Mon, 24 Jul 2023 04:29:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W+7EJVTO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231922AbjGXLAP (ORCPT + 99 others); Mon, 24 Jul 2023 07:00:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233281AbjGXLAM (ORCPT ); Mon, 24 Jul 2023 07:00:12 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AA7BE65; Mon, 24 Jul 2023 03:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690196394; x=1721732394; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=4sa+xq3Q9e41JXFT2qIhbuD5DTnjShAP6BzvAmrGcDM=; b=W+7EJVTOobD47VNvL25JkZaxeuCHN8OyRqPJs0YIqV2MyevCsAQfPfrt GZ/+PKvIUbZHa8vfpEewSL+k9j26FrESHkGRJY6IKrb0V/pujtZCUiUbP LL7QBQSW85yHO7Zm9lj8ZCF0FB2O6Qtw/AZRW+ZCZZanf/61g/qDpOqBB nNYIXpMPUg6xeIS5Ul3eTXuoS+L04JpMlcwtWyq+MfuxVIG9G5Yh+kqwq DNZBzSW0fy5dlCC6mO7gz7n3SS0fhEiAsJqZBMexMf3tq/OzlI6djeMCv iWz102C1uIWpVWp+c2UPQ+viW9gjiTVUBBY91YFIlIc4ejjOQRKOrrXmz g==; X-IronPort-AV: E=McAfee;i="6600,9927,10780"; a="347012264" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="347012264" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2023 03:59:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10780"; a="839409046" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="839409046" Received: from 984fee00a4c6.jf.intel.com ([10.165.58.231]) by fmsmga002.fm.intel.com with ESMTP; 24 Jul 2023 03:59:39 -0700 From: Yi Liu To: joro@8bytes.org, alex.williamson@redhat.com, jgg@nvidia.com, kevin.tian@intel.com, robin.murphy@arm.com, baolu.lu@linux.intel.com Cc: cohuck@redhat.com, eric.auger@redhat.com, nicolinc@nvidia.com, kvm@vger.kernel.org, mjrosato@linux.ibm.com, chao.p.peng@linux.intel.com, yi.l.liu@intel.com, yi.y.sun@linux.intel.com, peterx@redhat.com, jasowang@redhat.com, shameerali.kolothum.thodi@huawei.com, lulu@redhat.com, suravee.suthikulpanit@amd.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, zhenzhong.duan@intel.com Subject: [PATCH v4 2/4] iommu: Add new iommu op to get iommu hardware information Date: Mon, 24 Jul 2023 03:59:34 -0700 Message-Id: <20230724105936.107042-3-yi.l.liu@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230724105936.107042-1-yi.l.liu@intel.com> References: <20230724105936.107042-1-yi.l.liu@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772301253369664829 X-GMAIL-MSGID: 1772301253369664829 From: Lu Baolu Introduce a new iommu op to get the IOMMU hardware capabilities for iommufd. This information will be used by any vIOMMU driver which is owned by userspace. This op chooses to make the special parameters opaque to the core. This suits the current usage model where accessing any of the IOMMU device special parameters does require a userspace driver that matches the kernel driver. If a need for common parameters, implemented similarly by several drivers, arises then there's room in the design to grow a generic parameter set as well. No wrapper API is added as it is supposed to be used by iommufd only. Different IOMMU hardware would have different hardware information. So the information reported differs as well. To let the external user understand the difference. enum iommu_hw_info_type is defined. For the iommu drivers that are capable to report hardware information, it should have a unique iommu_hw_info_type. The iommu_hw_info_type is stored in struct iommu_ops. For the driver doesn't report hardware information, just use IOMMU_HW_INFO_TYPE_NONE. Signed-off-by: Lu Baolu Co-developed-by: Nicolin Chen Signed-off-by: Nicolin Chen Signed-off-by: Yi Liu --- include/linux/iommu.h | 16 ++++++++++++++++ include/uapi/linux/iommufd.h | 8 ++++++++ 2 files changed, 24 insertions(+) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index e0245aa82b75..4199e13b34e6 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -14,6 +14,7 @@ #include #include #include +#include #define IOMMU_READ (1 << 0) #define IOMMU_WRITE (1 << 1) @@ -228,6 +229,11 @@ struct iommu_iotlb_gather { /** * struct iommu_ops - iommu ops and capabilities * @capable: check capability + * @hw_info: IOMMU hardware information. The type of the returned data is + * marked by @hw_info_type. The data buffer returned by this op + * is allocated in the IOMMU driver and the caller should free it + * after use. Return the data buffer if success, or ERR_PTR on + * failure. * @domain_alloc: allocate iommu domain * @probe_device: Add device to iommu driver handling * @release_device: Remove device from iommu driver handling @@ -252,11 +258,20 @@ struct iommu_iotlb_gather { * @remove_dev_pasid: Remove any translation configurations of a specific * pasid, so that any DMA transactions with this pasid * will be blocked by the hardware. + * @hw_info_type: One of enum iommu_hw_info_type defined in + * include/uapi/linux/iommufd.h. It is used to tag the type + * of data returned by .hw_info callback. The drivers that + * support .hw_info callback should define a unique type + * in include/uapi/linux/iommufd.h. For the drivers that do + * not implement .hw_info callback, this field is + * IOMMU_HW_INFO_TYPE_NONE which is 0. Hence, such drivers + * do not need to care this field. * @pgsize_bitmap: bitmap of all possible supported page sizes * @owner: Driver module providing these ops */ struct iommu_ops { bool (*capable)(struct device *dev, enum iommu_cap); + void *(*hw_info)(struct device *dev, u32 *length); /* Domain allocation and freeing by the iommu driver */ struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type); @@ -285,6 +300,7 @@ struct iommu_ops { void (*remove_dev_pasid)(struct device *dev, ioasid_t pasid); const struct iommu_domain_ops *default_domain_ops; + enum iommu_hw_info_type hw_info_type; unsigned long pgsize_bitmap; struct module *owner; }; diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h index 8245c01adca6..1f616b0f8ae0 100644 --- a/include/uapi/linux/iommufd.h +++ b/include/uapi/linux/iommufd.h @@ -370,4 +370,12 @@ struct iommu_hwpt_alloc { __u32 __reserved; }; #define IOMMU_HWPT_ALLOC _IO(IOMMUFD_TYPE, IOMMUFD_CMD_HWPT_ALLOC) + +/** + * enum iommu_hw_info_type - IOMMU Hardware Info Types + * @IOMMU_HW_INFO_TYPE_NONE: Used by the drivers that does not report hardware info + */ +enum iommu_hw_info_type { + IOMMU_HW_INFO_TYPE_NONE, +}; #endif