Message ID | 20230209041642.9346-3-yi.l.liu@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp119288wrn; Wed, 8 Feb 2023 20:25:36 -0800 (PST) X-Google-Smtp-Source: AK7set8IBWVwR/XYVVU9D8q35JzH6L/LQiGCIWis0qzuexBQIG7+DJA4RdX8soa4SKtapG7Htp/l X-Received: by 2002:a50:ab01:0:b0:4a2:5f73:d3d2 with SMTP id s1-20020a50ab01000000b004a25f73d3d2mr9859498edc.41.1675916735982; Wed, 08 Feb 2023 20:25:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675916735; cv=none; d=google.com; s=arc-20160816; b=hIb046LLLsiezqJY2ooX0YJp10b+UXqiJwZ9iAjDHh286r7vSr8W4ddoGwP3MOFqkW xFhsKucgtTLY3DRxabZD4UxLtz9OtC0BUUHow1Qboc+ttV41HRUyTApB3q1jSBoM7b8n Pt3y5dd+7Py9YEjnM6vP+6EDhagUHlXDGWnSD31fvJMDLFCo5XltfU2bBYgdChzitA7O hvBlJ2eKe1wOMO0AN1J+y9xHcDeskIkPbjTlIiXT1rOgM67JF6Gv1ZoHHop776zq58Ja kJhOgIma7XNzsrvkc4lFBbWgC/vbjg9WQxNckVvAr3ZbfMJJQkQpz0zbmou8FGiMolN7 E0Rg== 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=QOo/HngJRIVy2pWqDbQuUwKA40SiUx6Gd9BXdqzc6Tk=; b=TY7kip1dOnRFmSc/PM7FNHw1lVZObNH73tdCMRUvUJD5eM+JKiyROk5E+C3WxFI7QN 3gySgsbUoHFYotaq20eZ27rigZ8+xOVjPCbT3jMMeZc5chiguHCFgByZ1FdMfKdLx3XD Fun5Nejn5vz3Ch/MI69IRRGClSmUy3Y2OAKcF0EjeP61sRlo6H2ErXWmHHNQ/fMt/fdB hemwnnsIncxfBTxAkjzxFrwtCqLiHOxu5G+SlgcpB+PWU2x7ay2FoGNtOMt5aHoWJ93O n+QzpE8YJ3thA4encU9uq6G5TcMkB2I1wtdhLi7ZNrcNE9CbZwEKakmA5eN+0O/YXQzH DNFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Ujdcylba; 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 c10-20020a056402100a00b004aac67f6f46si941688edu.17.2023.02.08.20.25.13; Wed, 08 Feb 2023 20:25:35 -0800 (PST) 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=Ujdcylba; 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 S229642AbjBIETw (ORCPT <rfc822;gnulinuxfreebsd@gmail.com> + 99 others); Wed, 8 Feb 2023 23:19:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229580AbjBIETs (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Feb 2023 23:19:48 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D7B837B46; Wed, 8 Feb 2023 20:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675916317; x=1707452317; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FHpZ/QqiMDOUDlV/6MH/yoSElx9gu3oQTNg7c3bopYs=; b=UjdcylbahddBAdOaH8Fjk75LslKMVyuzY7+zGkxwiwr1n5d1JOYvxkCK 5nIm6Bc7GXVnv6c8ceYHyTonqExmCIDkWBXAu5joCeB28m1QdHOUKGRIA H+cuIdO00cC0vrwImfj/+BLE4BvctprfFQjklDohGZtdi4Oh9ymvgm4Bh /6B7aNUmjCpF7KEtUtp6G9Kz7NsvCpSFzBEI1Uv5iZU2CvurkaFQse43E GrGy4fQSjNPc9h5Cz5c6x1i9zpIFr6nyGwJLMxbIaXcEmoJO6GjB+fNUk KjO1JLXMNaH8Wajm7Hie8/csnRKl8r8qmf+QRXS4ta48vclESUGNPniPQ w==; X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="394600718" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="394600718" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2023 20:16:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10615"; a="912982088" X-IronPort-AV: E=Sophos;i="5.97,281,1669104000"; d="scan'208";a="912982088" Received: from 984fee00a4c6.jf.intel.com ([10.165.58.231]) by fmsmga006.fm.intel.com with ESMTP; 08 Feb 2023 20:16:47 -0800 From: Yi Liu <yi.l.liu@intel.com> To: joro@8bytes.org, alex.williamson@redhat.com, jgg@nvidia.com, kevin.tian@intel.com, robin.murphy@arm.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, baolu.lu@linux.intel.com Subject: [PATCH 2/6] iommu/vt-d: Implement hw_info for iommu capability query Date: Wed, 8 Feb 2023 20:16:38 -0800 Message-Id: <20230209041642.9346-3-yi.l.liu@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230209041642.9346-1-yi.l.liu@intel.com> References: <20230209041642.9346-1-yi.l.liu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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_NONE,SPF_NONE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757326067297061813?= X-GMAIL-MSGID: =?utf-8?q?1757326067297061813?= |
Series |
iommufd: Add iommu capability reporting
|
|
Commit Message
Yi Liu
Feb. 9, 2023, 4:16 a.m. UTC
From: Lu Baolu <baolu.lu@linux.intel.com> To support nested translation in the userspace, it should check the underlying hardware information for the capabilities. Add intel_iommu_hw_info() to report cap_reg and ecap_reg information. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> --- drivers/iommu/intel/iommu.c | 19 +++++++++++++++++++ drivers/iommu/intel/iommu.h | 1 + include/uapi/linux/iommufd.h | 21 +++++++++++++++++++++ 3 files changed, 41 insertions(+)
Comments
> From: Liu, Yi L <yi.l.liu@intel.com> > Sent: Thursday, February 9, 2023 12:17 PM > > From: Lu Baolu <baolu.lu@linux.intel.com> > > To support nested translation in the userspace, it should check the > underlying hardware information for the capabilities. remove this sentence. that belongs to next patch. > + > +/** > + * struct iommu_device_info_vtd - Intel VT-d device info > + * > + * @flags: Must be set to 0 > + * @__reserved: Must be 0 > + * @cap_reg: Value of Intel VT-d capability register defined in chapter > + * 11.4.2 of Intel VT-d spec. > + * @ecap_reg: Value of Intel VT-d capability register defined in chapter > + * 11.4.3 of Intel VT-d spec. let's be specific with section name e.g. "11.4.2 Capability Register" so if the chapter index is changed later people can still know where to look at. > + * > + * Intel hardware iommu capability. duplicated with the first line "Intel VT-d device info"
On Wed, 8 Feb 2023 20:16:38 -0800 Yi Liu <yi.l.liu@intel.com> wrote: > From: Lu Baolu <baolu.lu@linux.intel.com> > > To support nested translation in the userspace, it should check the > underlying hardware information for the capabilities. > > Add intel_iommu_hw_info() to report cap_reg and ecap_reg information. > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > Signed-off-by: Yi Liu <yi.l.liu@intel.com> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> > --- > drivers/iommu/intel/iommu.c | 19 +++++++++++++++++++ > drivers/iommu/intel/iommu.h | 1 + > include/uapi/linux/iommufd.h | 21 +++++++++++++++++++++ > 3 files changed, 41 insertions(+) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index 59df7e42fd53..929f600cc350 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -4760,8 +4760,26 @@ static void intel_iommu_remove_dev_pasid(struct device *dev, ioasid_t pasid) > intel_pasid_tear_down_entry(iommu, dev, pasid, false); > } > > +static void *intel_iommu_hw_info(struct device *dev, u32 *length) > +{ > + struct device_domain_info *info = dev_iommu_priv_get(dev); > + struct intel_iommu *iommu = info->iommu; > + struct iommu_device_info_vtd *vtd; > + > + vtd = kzalloc(sizeof(*vtd), GFP_KERNEL); > + if (!vtd) > + return ERR_PTR(-ENOMEM); > + > + vtd->cap_reg = iommu->cap; > + vtd->ecap_reg = iommu->ecap; Just a friendly reminder that these registers are already exposed to userspace under /sys/class/iommu/ and each device has an iommu link back to their iommu device there. This series doesn't really stand on its own without some discussion of why that interface is not sufficient for this use case. Thanks, Alex
On Fri, Feb 10, 2023 at 03:44:10PM -0700, Alex Williamson wrote: > On Wed, 8 Feb 2023 20:16:38 -0800 > Yi Liu <yi.l.liu@intel.com> wrote: > > > From: Lu Baolu <baolu.lu@linux.intel.com> > > > > To support nested translation in the userspace, it should check the > > underlying hardware information for the capabilities. > > > > Add intel_iommu_hw_info() to report cap_reg and ecap_reg information. > > > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > > Signed-off-by: Yi Liu <yi.l.liu@intel.com> > > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > > Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> > > --- > > drivers/iommu/intel/iommu.c | 19 +++++++++++++++++++ > > drivers/iommu/intel/iommu.h | 1 + > > include/uapi/linux/iommufd.h | 21 +++++++++++++++++++++ > > 3 files changed, 41 insertions(+) > > > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > > index 59df7e42fd53..929f600cc350 100644 > > --- a/drivers/iommu/intel/iommu.c > > +++ b/drivers/iommu/intel/iommu.c > > @@ -4760,8 +4760,26 @@ static void intel_iommu_remove_dev_pasid(struct device *dev, ioasid_t pasid) > > intel_pasid_tear_down_entry(iommu, dev, pasid, false); > > } > > > > +static void *intel_iommu_hw_info(struct device *dev, u32 *length) > > +{ > > + struct device_domain_info *info = dev_iommu_priv_get(dev); > > + struct intel_iommu *iommu = info->iommu; > > + struct iommu_device_info_vtd *vtd; > > + > > + vtd = kzalloc(sizeof(*vtd), GFP_KERNEL); > > + if (!vtd) > > + return ERR_PTR(-ENOMEM); > > + > > + vtd->cap_reg = iommu->cap; > > + vtd->ecap_reg = iommu->ecap; > > Just a friendly reminder that these registers are already exposed to > userspace under /sys/class/iommu/ and each device has an iommu link > back to their iommu device there. I think in cases of mdevs w/ PASID (eg SIOV) it is not general to get from vfio sysfs to the sysfs path for the iommu. > This series doesn't really stand on its own without some discussion > of why that interface is not sufficient for this use case. IMHO I don't really like the idea of mixing iommufd with sysfs, it should stand on its own. In particular there is no generic way to go from a iommufd dev_id to any sysfs path, userspace would need prior unique knowledge about the subsystem that is being bound to iommufd first. So, I think some of those explanations would be good in the commit message? I would also add explanation about what userspace is supposed to do with these bits when it operates the nesting feature. Jason
On 2023/2/10 15:32, Tian, Kevin wrote: >> From: Liu, Yi L <yi.l.liu@intel.com> >> Sent: Thursday, February 9, 2023 12:17 PM >> >> From: Lu Baolu <baolu.lu@linux.intel.com> >> >> To support nested translation in the userspace, it should check the >> underlying hardware information for the capabilities. > > remove this sentence. that belongs to next patch. > >> + >> +/** >> + * struct iommu_device_info_vtd - Intel VT-d device info >> + * >> + * @flags: Must be set to 0 >> + * @__reserved: Must be 0 >> + * @cap_reg: Value of Intel VT-d capability register defined in chapter >> + * 11.4.2 of Intel VT-d spec. >> + * @ecap_reg: Value of Intel VT-d capability register defined in chapter >> + * 11.4.3 of Intel VT-d spec. > > let's be specific with section name e.g. "11.4.2 Capability Register" so if > the chapter index is changed later people can still know where to look > at. > >> + * >> + * Intel hardware iommu capability. > > duplicated with the first line "Intel VT-d device info" Above all agreed. Best regards, baolu
On 2/9/2023 12:16 PM, Yi Liu wrote: > From: Lu Baolu <baolu.lu@linux.intel.com> > > To support nested translation in the userspace, it should check the > underlying hardware information for the capabilities. > > Add intel_iommu_hw_info() to report cap_reg and ecap_reg information. > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > Signed-off-by: Yi Liu <yi.l.liu@intel.com> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> > --- > drivers/iommu/intel/iommu.c | 19 +++++++++++++++++++ > drivers/iommu/intel/iommu.h | 1 + > include/uapi/linux/iommufd.h | 21 +++++++++++++++++++++ > 3 files changed, 41 insertions(+) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index 59df7e42fd53..929f600cc350 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -4760,8 +4760,26 @@ static void intel_iommu_remove_dev_pasid(struct device *dev, ioasid_t pasid) > intel_pasid_tear_down_entry(iommu, dev, pasid, false); > } > > +static void *intel_iommu_hw_info(struct device *dev, u32 *length) > +{ > + struct device_domain_info *info = dev_iommu_priv_get(dev); > + struct intel_iommu *iommu = info->iommu; > + struct iommu_device_info_vtd *vtd; > + > + vtd = kzalloc(sizeof(*vtd), GFP_KERNEL); > + if (!vtd) > + return ERR_PTR(-ENOMEM); > + > + vtd->cap_reg = iommu->cap; > + vtd->ecap_reg = iommu->ecap; > + *length = sizeof(*vtd); > + > + return vtd; > +} > + > const struct iommu_ops intel_iommu_ops = { > .capable = intel_iommu_capable, > + .hw_info = intel_iommu_hw_info, > .domain_alloc = intel_iommu_domain_alloc, > .probe_device = intel_iommu_probe_device, > .probe_finalize = intel_iommu_probe_finalize, > @@ -4774,6 +4792,7 @@ const struct iommu_ops intel_iommu_ops = { > .def_domain_type = device_def_domain_type, > .remove_dev_pasid = intel_iommu_remove_dev_pasid, > .pgsize_bitmap = SZ_4K, > + .driver_type = IOMMU_DEVICE_DATA_INTEL_VTD, > #ifdef CONFIG_INTEL_IOMMU_SVM > .page_response = intel_svm_page_response, > #endif > diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h > index 06e61e474856..2e70265d4ceb 100644 > --- a/drivers/iommu/intel/iommu.h > +++ b/drivers/iommu/intel/iommu.h > @@ -22,6 +22,7 @@ > #include <linux/ioasid.h> > #include <linux/bitfield.h> > #include <linux/xarray.h> > +#include <uapi/linux/iommufd.h> > > #include <asm/cacheflush.h> > #include <asm/iommu.h> > diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h > index 2309edb55028..fda75c8450ee 100644 > --- a/include/uapi/linux/iommufd.h > +++ b/include/uapi/linux/iommufd.h > @@ -347,7 +347,28 @@ struct iommu_vfio_ioas { > > /** > * enum iommu_device_data_type - IOMMU hardware Data types > + * @IOMMU_DEVICE_DATA_INTEL_VTD: Intel VT-d iommu data type > */ > enum iommu_device_data_type { > + IOMMU_DEVICE_DATA_INTEL_VTD = 1, > +}; > + > +/** > + * struct iommu_device_info_vtd - Intel VT-d device info > + * > + * @flags: Must be set to 0 Could you add more description about the usage of flags here? > + * @__reserved: Must be 0 > + * @cap_reg: Value of Intel VT-d capability register defined in chapter > + * 11.4.2 of Intel VT-d spec. > + * @ecap_reg: Value of Intel VT-d capability register defined in chapter > + * 11.4.3 of Intel VT-d spec. > + * > + * Intel hardware iommu capability. > + */ > +struct iommu_device_info_vtd { > + __u32 flags; > + __u32 __reserved; > + __aligned_u64 cap_reg; > + __aligned_u64 ecap_reg; > }; > #endif
On 2023/2/13 11:09, Binbin Wu wrote: > > On 2/9/2023 12:16 PM, Yi Liu wrote: >> From: Lu Baolu <baolu.lu@linux.intel.com> >> >> To support nested translation in the userspace, it should check the >> underlying hardware information for the capabilities. >> >> Add intel_iommu_hw_info() to report cap_reg and ecap_reg information. >> >> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> >> Signed-off-by: Yi Liu <yi.l.liu@intel.com> >> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> >> Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> >> --- >> drivers/iommu/intel/iommu.c | 19 +++++++++++++++++++ >> drivers/iommu/intel/iommu.h | 1 + >> include/uapi/linux/iommufd.h | 21 +++++++++++++++++++++ >> 3 files changed, 41 insertions(+) >> >> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c >> index 59df7e42fd53..929f600cc350 100644 >> --- a/drivers/iommu/intel/iommu.c >> +++ b/drivers/iommu/intel/iommu.c >> @@ -4760,8 +4760,26 @@ static void intel_iommu_remove_dev_pasid(struct >> device *dev, ioasid_t pasid) >> intel_pasid_tear_down_entry(iommu, dev, pasid, false); >> } >> +static void *intel_iommu_hw_info(struct device *dev, u32 *length) >> +{ >> + struct device_domain_info *info = dev_iommu_priv_get(dev); >> + struct intel_iommu *iommu = info->iommu; >> + struct iommu_device_info_vtd *vtd; >> + >> + vtd = kzalloc(sizeof(*vtd), GFP_KERNEL); >> + if (!vtd) >> + return ERR_PTR(-ENOMEM); >> + >> + vtd->cap_reg = iommu->cap; >> + vtd->ecap_reg = iommu->ecap; >> + *length = sizeof(*vtd); >> + >> + return vtd; >> +} >> + >> const struct iommu_ops intel_iommu_ops = { >> .capable = intel_iommu_capable, >> + .hw_info = intel_iommu_hw_info, >> .domain_alloc = intel_iommu_domain_alloc, >> .probe_device = intel_iommu_probe_device, >> .probe_finalize = intel_iommu_probe_finalize, >> @@ -4774,6 +4792,7 @@ const struct iommu_ops intel_iommu_ops = { >> .def_domain_type = device_def_domain_type, >> .remove_dev_pasid = intel_iommu_remove_dev_pasid, >> .pgsize_bitmap = SZ_4K, >> + .driver_type = IOMMU_DEVICE_DATA_INTEL_VTD, >> #ifdef CONFIG_INTEL_IOMMU_SVM >> .page_response = intel_svm_page_response, >> #endif >> diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h >> index 06e61e474856..2e70265d4ceb 100644 >> --- a/drivers/iommu/intel/iommu.h >> +++ b/drivers/iommu/intel/iommu.h >> @@ -22,6 +22,7 @@ >> #include <linux/ioasid.h> >> #include <linux/bitfield.h> >> #include <linux/xarray.h> >> +#include <uapi/linux/iommufd.h> >> #include <asm/cacheflush.h> >> #include <asm/iommu.h> >> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h >> index 2309edb55028..fda75c8450ee 100644 >> --- a/include/uapi/linux/iommufd.h >> +++ b/include/uapi/linux/iommufd.h >> @@ -347,7 +347,28 @@ struct iommu_vfio_ioas { >> /** >> * enum iommu_device_data_type - IOMMU hardware Data types >> + * @IOMMU_DEVICE_DATA_INTEL_VTD: Intel VT-d iommu data type >> */ >> enum iommu_device_data_type { >> + IOMMU_DEVICE_DATA_INTEL_VTD = 1, >> +}; >> + >> +/** >> + * struct iommu_device_info_vtd - Intel VT-d device info >> + * >> + * @flags: Must be set to 0 > > Could you add more description about the usage of flags here? This is a Reserved 0 fields for other coming features. Best regards, baolu
On Wed, Feb 08, 2023 at 08:16:38PM -0800, Yi Liu wrote: > From: Lu Baolu <baolu.lu@linux.intel.com> > > To support nested translation in the userspace, it should check the > underlying hardware information for the capabilities. > > Add intel_iommu_hw_info() to report cap_reg and ecap_reg information. > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > Signed-off-by: Yi Liu <yi.l.liu@intel.com> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com> > --- > drivers/iommu/intel/iommu.c | 19 +++++++++++++++++++ > drivers/iommu/intel/iommu.h | 1 + > include/uapi/linux/iommufd.h | 21 +++++++++++++++++++++ > 3 files changed, 41 insertions(+) This should come after the next patch in the series Jason
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 59df7e42fd53..929f600cc350 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -4760,8 +4760,26 @@ static void intel_iommu_remove_dev_pasid(struct device *dev, ioasid_t pasid) intel_pasid_tear_down_entry(iommu, dev, pasid, false); } +static void *intel_iommu_hw_info(struct device *dev, u32 *length) +{ + struct device_domain_info *info = dev_iommu_priv_get(dev); + struct intel_iommu *iommu = info->iommu; + struct iommu_device_info_vtd *vtd; + + vtd = kzalloc(sizeof(*vtd), GFP_KERNEL); + if (!vtd) + return ERR_PTR(-ENOMEM); + + vtd->cap_reg = iommu->cap; + vtd->ecap_reg = iommu->ecap; + *length = sizeof(*vtd); + + return vtd; +} + const struct iommu_ops intel_iommu_ops = { .capable = intel_iommu_capable, + .hw_info = intel_iommu_hw_info, .domain_alloc = intel_iommu_domain_alloc, .probe_device = intel_iommu_probe_device, .probe_finalize = intel_iommu_probe_finalize, @@ -4774,6 +4792,7 @@ const struct iommu_ops intel_iommu_ops = { .def_domain_type = device_def_domain_type, .remove_dev_pasid = intel_iommu_remove_dev_pasid, .pgsize_bitmap = SZ_4K, + .driver_type = IOMMU_DEVICE_DATA_INTEL_VTD, #ifdef CONFIG_INTEL_IOMMU_SVM .page_response = intel_svm_page_response, #endif diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 06e61e474856..2e70265d4ceb 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -22,6 +22,7 @@ #include <linux/ioasid.h> #include <linux/bitfield.h> #include <linux/xarray.h> +#include <uapi/linux/iommufd.h> #include <asm/cacheflush.h> #include <asm/iommu.h> diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h index 2309edb55028..fda75c8450ee 100644 --- a/include/uapi/linux/iommufd.h +++ b/include/uapi/linux/iommufd.h @@ -347,7 +347,28 @@ struct iommu_vfio_ioas { /** * enum iommu_device_data_type - IOMMU hardware Data types + * @IOMMU_DEVICE_DATA_INTEL_VTD: Intel VT-d iommu data type */ enum iommu_device_data_type { + IOMMU_DEVICE_DATA_INTEL_VTD = 1, +}; + +/** + * struct iommu_device_info_vtd - Intel VT-d device info + * + * @flags: Must be set to 0 + * @__reserved: Must be 0 + * @cap_reg: Value of Intel VT-d capability register defined in chapter + * 11.4.2 of Intel VT-d spec. + * @ecap_reg: Value of Intel VT-d capability register defined in chapter + * 11.4.3 of Intel VT-d spec. + * + * Intel hardware iommu capability. + */ +struct iommu_device_info_vtd { + __u32 flags; + __u32 __reserved; + __aligned_u64 cap_reg; + __aligned_u64 ecap_reg; }; #endif