Message ID | 20231127063428.127436-9-yi.l.liu@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce62:0:b0:403:3b70:6f57 with SMTP id o2csp2888646vqx; Sun, 26 Nov 2023 22:36:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IHiyXi4eXWX/R0WX4q4ijY2TGwaluhOTeOo5i1tmjSvTvDmt82aXsTlXWGs8z8MxkRKMqX4 X-Received: by 2002:a05:6a20:4b2a:b0:186:5a25:a3f1 with SMTP id fp42-20020a056a204b2a00b001865a25a3f1mr8557333pzb.37.1701066963685; Sun, 26 Nov 2023 22:36:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701066963; cv=none; d=google.com; s=arc-20160816; b=RYn0uoIuL7ZWJoNWNAi9uHAfxM83YCOUDJVQkY5QHR+bxyLADbgW9Re1Yo3UcCtrrM oUwW/KnUNdUNc/Ae8RO0RHh3DKHM38ZkIUZgeisYhU/WXVcAChm1UwfiNNyGEznkZAYr kr2CTtf3DhpaeL06FOaCLVCQJQRjGl/3uMxRg5STdzulfre87Kk9upuUguTHm1KdaD5/ kc9Dn+PehI6sWgkp4cQ/tFYzoRxnP1QnXrDbIpaB+lmgAEcJXCzsKtJbNM/bahQvFM3D CjBd+6wRaUGxCV1O46Lm4eGF06SrzoNIGB+1jtfDUq3AsVtAU5xieoS5D0jBsxQKwl2s /euA== 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=JBUGfp90RnJixjQhuyTu5YrTFhLW5SNELpge3DShX6A=; fh=gm0A6EtasJwovXfz1TpeYfkY+4H0EN5E4rSCpite+Dk=; b=gVuz7tIwi2DXORl0aoBSi0ZcwkfyZPJ1UynWtn11LO9v6I+hlsj4zriQA4ThuNGIdM Mp7qRnMOH0X7Kg+prqVvds5wdKIYp7r8tMiiw8wI6BKaL6QTOkzL+656z++Jjy+TF1Tu 2YulGnZaS0QIeBB8EP7mmaVlA+aIkQ5hAPQNHhKuSOn/g/f3ox5RZcG+Ad9pKjBOFa+C OEc/X8kDmObHF8iz3FbekBhAy/7MJDUC026g+IVrD9uBRs5lAZ3dc90LM0n4KuA7aR70 j4kQd4UGipqXEDewOuHDk4Qs6QojcNHPYMvi8L00vQUmQgdg9r5lyGuNP93/oiB657Wn ti+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=WMOc+SeD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id d4-20020a170903230400b001cfd934bd7bsi306496plh.409.2023.11.26.22.36.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Nov 2023 22:36:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=WMOc+SeD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 08816807F2A8; Sun, 26 Nov 2023 22:35:43 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231234AbjK0GfA (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Mon, 27 Nov 2023 01:35:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39062 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232287AbjK0Gei (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 27 Nov 2023 01:34:38 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 869AE134; Sun, 26 Nov 2023 22:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701066884; x=1732602884; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=B5xzEcpuIinwDW3kyMTLhid13bUB/51PdRBylLP/hwc=; b=WMOc+SeDd+1A6HWtc6+V1lp0gAvZKiZ/ANs8nkA52qW1fFPdLr7t1Mkn cu/uDDkRUuv2thULCkiN4TqNA0P5BIY7qzK1A/VsPC2YFVIBMWTCI59jF FeSu/hMrWw1WcmUtzvU9zj//R6bNmFoGbvzCi7K1dcB3K9iSuT09CkzZs zbqHs9Oja5XyoUUbFEo5hJXiLGSz3nRX+9cLg8PHtzV/wUI3HkQJEbn8R IFuBkrytzP3d6zul3chVlKZ8AqWfiTEi8Y8ac59XEANG9aYJcjrGj44l1 eJ9xwYr58kPzDQym1jpFo5o3QGZmYJ58owAktYF2fSa/NWnmgMGQybl9y g==; X-IronPort-AV: E=McAfee;i="6600,9927,10906"; a="391518220" X-IronPort-AV: E=Sophos;i="6.04,230,1695711600"; d="scan'208";a="391518220" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2023 22:34:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10906"; a="838608958" X-IronPort-AV: E=Sophos;i="6.04,230,1695711600"; d="scan'208";a="838608958" Received: from 984fee00a4c6.jf.intel.com ([10.165.58.231]) by fmsmga004.fm.intel.com with ESMTP; 26 Nov 2023 22:34:43 -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, 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, joao.m.martins@oracle.com, xin.zeng@intel.com, yan.y.zhao@intel.com Subject: [PATCH 8/8] iommu/vt-d: Add set_dev_pasid callback for nested domain Date: Sun, 26 Nov 2023 22:34:28 -0800 Message-Id: <20231127063428.127436-9-yi.l.liu@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231127063428.127436-1-yi.l.liu@intel.com> References: <20231127063428.127436-1-yi.l.liu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Sun, 26 Nov 2023 22:35:43 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783697992366018171 X-GMAIL-MSGID: 1783697992366018171 |
Series |
iommufd support pasid attach/replace
|
|
Commit Message
Yi Liu
Nov. 27, 2023, 6:34 a.m. UTC
From: Lu Baolu <baolu.lu@linux.intel.com> This allows the upper layers to set a nested type domain to a PASID of a device if the PASID feature is supported by the IOMMU hardware. The set_dev_pasid callback for non-nest domain has already be there, so this only needs to add it for nested domains. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Yi Liu <yi.l.liu@intel.com> --- drivers/iommu/intel/nested.c | 47 ++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)
Comments
On 11/27/2023 2:34 PM, Yi Liu wrote: > From: Lu Baolu <baolu.lu@linux.intel.com> > > This allows the upper layers to set a nested type domain to a PASID of a > device if the PASID feature is supported by the IOMMU hardware. > > The set_dev_pasid callback for non-nest domain has already be there, so > this only needs to add it for nested domains. > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > Signed-off-by: Yi Liu <yi.l.liu@intel.com> > --- > drivers/iommu/intel/nested.c | 47 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > > diff --git a/drivers/iommu/intel/nested.c b/drivers/iommu/intel/nested.c > index 44ad48db7ea0..f6f687750104 100644 > --- a/drivers/iommu/intel/nested.c > +++ b/drivers/iommu/intel/nested.c > @@ -68,6 +68,52 @@ static int intel_nested_attach_dev(struct iommu_domain *domain, > return 0; > } > > +static int intel_nested_set_dev_pasid(struct iommu_domain *domain, > + struct device *dev, ioasid_t pasid) > +{ > + struct device_domain_info *info = dev_iommu_priv_get(dev); > + struct dmar_domain *dmar_domain = to_dmar_domain(domain); > + struct intel_iommu *iommu = info->iommu; > + struct dev_pasid_info *dev_pasid; > + unsigned long flags; > + int ret = 0; > + > + if (!pasid_supported(iommu)) > + return -EOPNOTSUPP; > + > + if (iommu->agaw < dmar_domain->s2_domain->agaw) > + return -EINVAL; > + > + ret = prepare_domain_attach_device(&dmar_domain->s2_domain->domain, dev); > + if (ret) > + return ret; > + > + dev_pasid = kzalloc(sizeof(*dev_pasid), GFP_KERNEL); > + if (!dev_pasid) > + return -ENOMEM; > + > + ret = domain_attach_iommu(dmar_domain, iommu); > + if (ret) > + goto err_free; > + > + ret = intel_pasid_setup_nested(iommu, dev, pasid, dmar_domain); > + if (ret) > + goto err_detach_iommu; > + > + dev_pasid->dev = dev; > + dev_pasid->pasid = pasid; > + spin_lock_irqsave(&dmar_domain->lock, flags); > + list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); > + spin_unlock_irqrestore(&dmar_domain->lock, flags); ---> list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); dev_pasid is linked at later time, this leads to domain->has_iotlb_device is not correctly set, which finally results into a missing of device iotlb flush in iommu_flush_dev_iotlb()when it's called. Check this call path: domain_attach_iommu()->domain_update_iommu_cap()->domain_update_iotlb()->domain->has_iotlb_device = has_iotlb_device; The ugly fixup is to call domain_update_iommu_cap() or domain_update_iotlb() here again before return. The similar issue is in intel_iommu_set_dev_pasid() and intel_nested_attach_dev(). > + > + return 0; > +err_detach_iommu: > + domain_detach_iommu(dmar_domain, iommu); > +err_free: > + kfree(dev_pasid); > + return ret; > +} > + > static void intel_nested_domain_free(struct iommu_domain *domain) > { > kfree(to_dmar_domain(domain)); > @@ -128,6 +174,7 @@ static int intel_nested_cache_invalidate_user(struct iommu_domain *domain, > > static const struct iommu_domain_ops intel_nested_domain_ops = { > .attach_dev = intel_nested_attach_dev, > + .set_dev_pasid = intel_nested_set_dev_pasid, > .free = intel_nested_domain_free, > .cache_invalidate_user = intel_nested_cache_invalidate_user, > };
On 2023/12/14 10:55, Yang, Weijiang wrote: > On 11/27/2023 2:34 PM, Yi Liu wrote: >> From: Lu Baolu <baolu.lu@linux.intel.com> >> >> This allows the upper layers to set a nested type domain to a PASID of a >> device if the PASID feature is supported by the IOMMU hardware. >> >> The set_dev_pasid callback for non-nest domain has already be there, so >> this only needs to add it for nested domains. >> >> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> >> Signed-off-by: Yi Liu <yi.l.liu@intel.com> >> --- >> drivers/iommu/intel/nested.c | 47 ++++++++++++++++++++++++++++++++++++ >> 1 file changed, 47 insertions(+) >> >> diff --git a/drivers/iommu/intel/nested.c b/drivers/iommu/intel/nested.c >> index 44ad48db7ea0..f6f687750104 100644 >> --- a/drivers/iommu/intel/nested.c >> +++ b/drivers/iommu/intel/nested.c >> @@ -68,6 +68,52 @@ static int intel_nested_attach_dev(struct >> iommu_domain *domain, >> return 0; >> } >> +static int intel_nested_set_dev_pasid(struct iommu_domain *domain, >> + struct device *dev, ioasid_t pasid) >> +{ >> + struct device_domain_info *info = dev_iommu_priv_get(dev); >> + struct dmar_domain *dmar_domain = to_dmar_domain(domain); >> + struct intel_iommu *iommu = info->iommu; >> + struct dev_pasid_info *dev_pasid; >> + unsigned long flags; >> + int ret = 0; >> + >> + if (!pasid_supported(iommu)) >> + return -EOPNOTSUPP; >> + >> + if (iommu->agaw < dmar_domain->s2_domain->agaw) >> + return -EINVAL; >> + >> + ret = >> prepare_domain_attach_device(&dmar_domain->s2_domain->domain, dev); >> + if (ret) >> + return ret; >> + >> + dev_pasid = kzalloc(sizeof(*dev_pasid), GFP_KERNEL); >> + if (!dev_pasid) >> + return -ENOMEM; >> + >> + ret = domain_attach_iommu(dmar_domain, iommu); >> + if (ret) >> + goto err_free; >> + >> + ret = intel_pasid_setup_nested(iommu, dev, pasid, dmar_domain); >> + if (ret) >> + goto err_detach_iommu; >> + >> + dev_pasid->dev = dev; >> + dev_pasid->pasid = pasid; >> + spin_lock_irqsave(&dmar_domain->lock, flags); >> + list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); >> + spin_unlock_irqrestore(&dmar_domain->lock, flags); > > ---> list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); > > dev_pasid is linked at later time, this leads to > domain->has_iotlb_device is not correctly set, which finally results > into a missing of device iotlb flush in iommu_flush_dev_iotlb()when it's > called. > Check this call path: > domain_attach_iommu()->domain_update_iommu_cap()->domain_update_iotlb()->domain->has_iotlb_device = has_iotlb_device; The ugly fixup is to call domain_update_iommu_cap() or domain_update_iotlb() here again before return. > The similar issue is in intel_iommu_set_dev_pasid() and > intel_nested_attach_dev(). Yes, domain->has_iotlb_device must be updated whenever a domain is attached to (or removed from) a RID or PASID. I would be grateful if you could post some patches to fix the set_device_pasid and nested_attach_dev paths. I assume Yi can fix this series in the next version. Best regards, baolu
On 12/14/2023 9:33 PM, Baolu Lu wrote: > On 2023/12/14 10:55, Yang, Weijiang wrote: >> On 11/27/2023 2:34 PM, Yi Liu wrote: >>> From: Lu Baolu <baolu.lu@linux.intel.com> >>> >>> This allows the upper layers to set a nested type domain to a PASID of a >>> device if the PASID feature is supported by the IOMMU hardware. >>> >>> The set_dev_pasid callback for non-nest domain has already be there, so >>> this only needs to add it for nested domains. >>> >>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> >>> Signed-off-by: Yi Liu <yi.l.liu@intel.com> >>> --- >>> drivers/iommu/intel/nested.c | 47 ++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 47 insertions(+) >>> >>> diff --git a/drivers/iommu/intel/nested.c b/drivers/iommu/intel/nested.c >>> index 44ad48db7ea0..f6f687750104 100644 >>> --- a/drivers/iommu/intel/nested.c >>> +++ b/drivers/iommu/intel/nested.c >>> @@ -68,6 +68,52 @@ static int intel_nested_attach_dev(struct iommu_domain *domain, >>> return 0; >>> } >>> +static int intel_nested_set_dev_pasid(struct iommu_domain *domain, >>> + struct device *dev, ioasid_t pasid) >>> +{ >>> + struct device_domain_info *info = dev_iommu_priv_get(dev); >>> + struct dmar_domain *dmar_domain = to_dmar_domain(domain); >>> + struct intel_iommu *iommu = info->iommu; >>> + struct dev_pasid_info *dev_pasid; >>> + unsigned long flags; >>> + int ret = 0; >>> + >>> + if (!pasid_supported(iommu)) >>> + return -EOPNOTSUPP; >>> + >>> + if (iommu->agaw < dmar_domain->s2_domain->agaw) >>> + return -EINVAL; >>> + >>> + ret = prepare_domain_attach_device(&dmar_domain->s2_domain->domain, dev); >>> + if (ret) >>> + return ret; >>> + >>> + dev_pasid = kzalloc(sizeof(*dev_pasid), GFP_KERNEL); >>> + if (!dev_pasid) >>> + return -ENOMEM; >>> + >>> + ret = domain_attach_iommu(dmar_domain, iommu); >>> + if (ret) >>> + goto err_free; >>> + >>> + ret = intel_pasid_setup_nested(iommu, dev, pasid, dmar_domain); >>> + if (ret) >>> + goto err_detach_iommu; >>> + >>> + dev_pasid->dev = dev; >>> + dev_pasid->pasid = pasid; >>> + spin_lock_irqsave(&dmar_domain->lock, flags); >>> + list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); >>> + spin_unlock_irqrestore(&dmar_domain->lock, flags); >> >> ---> list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); >> >> dev_pasid is linked at later time, this leads to domain->has_iotlb_device is not correctly set, which finally results into a missing of device iotlb flush in iommu_flush_dev_iotlb()when it's called. >> Check this call path: >> domain_attach_iommu()->domain_update_iommu_cap()->domain_update_iotlb()->domain->has_iotlb_device = has_iotlb_device; The ugly fixup is to call domain_update_iommu_cap() or domain_update_iotlb() here again before return. >> The similar issue is in intel_iommu_set_dev_pasid() and intel_nested_attach_dev(). > > Yes, domain->has_iotlb_device must be updated whenever a domain is > attached to (or removed from) a RID or PASID. I would be grateful if you > could post some patches to fix the set_device_pasid and > nested_attach_dev paths. Sure, I'll post fixup patches for the paths, thanks for confirmation! > > I assume Yi can fix this series in the next version. > > Best regards, > baolu
On Sun, Nov 26, 2023 at 10:34:28PM -0800, Yi Liu wrote: > +static int intel_nested_set_dev_pasid(struct iommu_domain *domain, > + struct device *dev, ioasid_t pasid) > +{ > + struct device_domain_info *info = dev_iommu_priv_get(dev); > + struct dmar_domain *dmar_domain = to_dmar_domain(domain); > + struct intel_iommu *iommu = info->iommu; > + struct dev_pasid_info *dev_pasid; > + unsigned long flags; > + int ret = 0; > + > + if (!pasid_supported(iommu)) > + return -EOPNOTSUPP; > + > + if (iommu->agaw < dmar_domain->s2_domain->agaw) > + return -EINVAL; > + > + ret = prepare_domain_attach_device(&dmar_domain->s2_domain->domain, dev); > + if (ret) > + return ret; > + > + dev_pasid = kzalloc(sizeof(*dev_pasid), GFP_KERNEL); > + if (!dev_pasid) > + return -ENOMEM; > + > + ret = domain_attach_iommu(dmar_domain, iommu); > + if (ret) > + goto err_free; > + > + ret = intel_pasid_setup_nested(iommu, dev, pasid, dmar_domain); > + if (ret) > + goto err_detach_iommu; > + > + dev_pasid->dev = dev; > + dev_pasid->pasid = pasid; > + spin_lock_irqsave(&dmar_domain->lock, flags); > + list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); > + spin_unlock_irqrestore(&dmar_domain->lock, flags); > + > + return 0; > +err_detach_iommu: > + domain_detach_iommu(dmar_domain, iommu); > +err_free: > + kfree(dev_pasid); > + return ret; > +} This seems alot longer than I'd think it should be, why isn't it exactly the same code as the other set_dev_pasid's? Jason
On 2024/1/16 1:22, Jason Gunthorpe wrote: > On Sun, Nov 26, 2023 at 10:34:28PM -0800, Yi Liu wrote: > >> +static int intel_nested_set_dev_pasid(struct iommu_domain *domain, >> + struct device *dev, ioasid_t pasid) >> +{ >> + struct device_domain_info *info = dev_iommu_priv_get(dev); >> + struct dmar_domain *dmar_domain = to_dmar_domain(domain); >> + struct intel_iommu *iommu = info->iommu; >> + struct dev_pasid_info *dev_pasid; >> + unsigned long flags; >> + int ret = 0; >> + >> + if (!pasid_supported(iommu)) >> + return -EOPNOTSUPP; >> + >> + if (iommu->agaw < dmar_domain->s2_domain->agaw) >> + return -EINVAL; >> + >> + ret = prepare_domain_attach_device(&dmar_domain->s2_domain->domain, dev); >> + if (ret) >> + return ret; >> + >> + dev_pasid = kzalloc(sizeof(*dev_pasid), GFP_KERNEL); >> + if (!dev_pasid) >> + return -ENOMEM; >> + >> + ret = domain_attach_iommu(dmar_domain, iommu); >> + if (ret) >> + goto err_free; >> + >> + ret = intel_pasid_setup_nested(iommu, dev, pasid, dmar_domain); >> + if (ret) >> + goto err_detach_iommu; >> + >> + dev_pasid->dev = dev; >> + dev_pasid->pasid = pasid; >> + spin_lock_irqsave(&dmar_domain->lock, flags); >> + list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); >> + spin_unlock_irqrestore(&dmar_domain->lock, flags); >> + >> + return 0; >> +err_detach_iommu: >> + domain_detach_iommu(dmar_domain, iommu); >> +err_free: >> + kfree(dev_pasid); >> + return ret; >> +} > This seems alot longer than I'd think it should be, why isn't it > exactly the same code as the other set_dev_pasid's? Yes. It should be. The only difference is how to configure the pasid entry. Best regards, baolu
diff --git a/drivers/iommu/intel/nested.c b/drivers/iommu/intel/nested.c index 44ad48db7ea0..f6f687750104 100644 --- a/drivers/iommu/intel/nested.c +++ b/drivers/iommu/intel/nested.c @@ -68,6 +68,52 @@ static int intel_nested_attach_dev(struct iommu_domain *domain, return 0; } +static int intel_nested_set_dev_pasid(struct iommu_domain *domain, + struct device *dev, ioasid_t pasid) +{ + struct device_domain_info *info = dev_iommu_priv_get(dev); + struct dmar_domain *dmar_domain = to_dmar_domain(domain); + struct intel_iommu *iommu = info->iommu; + struct dev_pasid_info *dev_pasid; + unsigned long flags; + int ret = 0; + + if (!pasid_supported(iommu)) + return -EOPNOTSUPP; + + if (iommu->agaw < dmar_domain->s2_domain->agaw) + return -EINVAL; + + ret = prepare_domain_attach_device(&dmar_domain->s2_domain->domain, dev); + if (ret) + return ret; + + dev_pasid = kzalloc(sizeof(*dev_pasid), GFP_KERNEL); + if (!dev_pasid) + return -ENOMEM; + + ret = domain_attach_iommu(dmar_domain, iommu); + if (ret) + goto err_free; + + ret = intel_pasid_setup_nested(iommu, dev, pasid, dmar_domain); + if (ret) + goto err_detach_iommu; + + dev_pasid->dev = dev; + dev_pasid->pasid = pasid; + spin_lock_irqsave(&dmar_domain->lock, flags); + list_add(&dev_pasid->link_domain, &dmar_domain->dev_pasids); + spin_unlock_irqrestore(&dmar_domain->lock, flags); + + return 0; +err_detach_iommu: + domain_detach_iommu(dmar_domain, iommu); +err_free: + kfree(dev_pasid); + return ret; +} + static void intel_nested_domain_free(struct iommu_domain *domain) { kfree(to_dmar_domain(domain)); @@ -128,6 +174,7 @@ static int intel_nested_cache_invalidate_user(struct iommu_domain *domain, static const struct iommu_domain_ops intel_nested_domain_ops = { .attach_dev = intel_nested_attach_dev, + .set_dev_pasid = intel_nested_set_dev_pasid, .free = intel_nested_domain_free, .cache_invalidate_user = intel_nested_cache_invalidate_user, };