Message ID | 20230309025639.26109-3-baolu.lu@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp61803wrd; Wed, 8 Mar 2023 18:59:41 -0800 (PST) X-Google-Smtp-Source: AK7set+PcSrPkLnUbKG1CcI4nL2pSJqJEnMngd8KSE9XIZ+0dN3t95bh8/AqqBS9hiCfnHzhkPsg X-Received: by 2002:a17:902:720b:b0:19a:7758:e5e6 with SMTP id ba11-20020a170902720b00b0019a7758e5e6mr17056142plb.48.1678330780866; Wed, 08 Mar 2023 18:59:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678330780; cv=none; d=google.com; s=arc-20160816; b=pkc0wkFYCDK9lyiEFZYXyS3z0iyminOxJFX6XadNsN5c7lsVUOOGwVEyLsY0aFKhYD uoCq47f9mVZCvFIXuHrY9bboyoMDAbK/7SojleBjC5eB0cIBPQSpmslq4HwbCyqGrC/L ZMe6B60mD72oqrZke7Ds0UVxvaTFx0ir507sgRrcAcxXLcEhdAbgSoXscquXnb/Y6KJi +on0y/JG3JR7a9oQ1C2cJvgMTveatcEYfqHAQTjEuod4+O+ZnyAluofD8wtCZVp3lA0J 0DQfBoP/+UoDnd+TdSAw1VIAGn0ehJqMiAHDIKSc/pn+TxrL1CmIHfwlHeFVNtwe/sEn V5tw== 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=cUqP0DoO5xn3OuP+kxqhlYJ/l6D8h5bmQOVw0yNk3OM=; b=xUMyuYszaXF+pk6/7fRQ/882/ymc5ZViGYKKnAxPwjGn83/z5KFQ6wCK9gYHsvG2uR HwYxk0jsnuD+5/R7QTCbrbYLSGcs9qq8TbwWzhVJ4+wbJdMk0Zn+iY5af+JhHWCO4ZvK 1qA/DSxG2F2QB+KmeB15BjJ5nKTRJ28uaHJcVtSs9dCRDKINVsJBO0NUjccUCzC3bFsH rlYmG/KccM44IZI07+ZkPTSVlr0ji+8EVmb+t9QLxg4jJ7YwUps0tw69V5en7eVZDf4h CkNUltiiB1Y/zXigPy4rMXnxQAxk98ABW4mnIvKMKzVlak3O9XOCyGTZ1DuEQJ2Bin0D g7IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PPxFmRDv; 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 y1-20020a1709027c8100b001943e4426a2si16212583pll.431.2023.03.08.18.59.26; Wed, 08 Mar 2023 18:59:40 -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=PPxFmRDv; 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 S229958AbjCIC54 (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Wed, 8 Mar 2023 21:57:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229941AbjCIC5w (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Mar 2023 21:57:52 -0500 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42F6393E28; Wed, 8 Mar 2023 18:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678330671; x=1709866671; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=QiXay9B0/cIAt+xudzeSslyrWr7mHV5btFCAUOhzZSY=; b=PPxFmRDvHxBKoeUka0ZcsPRp+1bMbvOVNvUTRF6sCG8RvEAhHeQUsCx8 5gj2oscSkqY1mp6WQ5fGDHjN/UITF4VOIoQbtKW8gZCHDFz3mHblYoc1I WRxz4zjxF94NDjh3eYoxtwmLKR3eU74F6L+HQI78WKe4CJ9AbWGxtw0fA TNPIZe87cQyLpPU2rhpCnDQwmxj3G6i4zk1Bdo1ASdVrbnqlW85WFZG55 H3od8BtlvQoTt3AE6uJncYgSYBHn1oOgeZcBgk/yLVMtPTzTo57azl93G RHPbCAn2qAM1VovoZ+qqushtjm/FcRrXBCz4vcxrnk1DR4ntpNNiS//uU g==; X-IronPort-AV: E=McAfee;i="6500,9779,10643"; a="316732654" X-IronPort-AV: E=Sophos;i="5.98,245,1673942400"; d="scan'208";a="316732654" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2023 18:57:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10643"; a="746144621" X-IronPort-AV: E=Sophos;i="5.98,245,1673942400"; d="scan'208";a="746144621" Received: from allen-box.sh.intel.com ([10.239.159.48]) by fmsmga004.fm.intel.com with ESMTP; 08 Mar 2023 18:57:48 -0800 From: Lu Baolu <baolu.lu@linux.intel.com> To: iommu@lists.linux.dev, dmaengine@vger.kernel.org Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, Kevin Tian <kevin.tian@intel.com>, Fenghua Yu <fenghua.yu@intel.com>, Dave Jiang <dave.jiang@intel.com>, Vinod Koul <vkoul@kernel.org>, Jacob Pan <jacob.jun.pan@linux.intel.com>, linux-kernel@vger.kernel.org, Lu Baolu <baolu.lu@linux.intel.com> Subject: [PATCH v2 2/5] iommu/vt-d: Allow SVA with device-specific IOPF Date: Thu, 9 Mar 2023 10:56:36 +0800 Message-Id: <20230309025639.26109-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230309025639.26109-1-baolu.lu@linux.intel.com> References: <20230309025639.26109-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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?1759857376917498734?= X-GMAIL-MSGID: =?utf-8?q?1759857376917498734?= |
Series |
Refactor code for non-PRI IOPF
|
|
Commit Message
Baolu Lu
March 9, 2023, 2:56 a.m. UTC
Currently enabling SVA requires IOPF support from the IOMMU and device
PCI PRI. However, some devices can handle IOPF by itself without ever
sending PCI page requests nor advertising PRI capability.
Allow SVA support with IOPF handled either by IOMMU (PCI PRI) or device
driver (device-specific IOPF). As long as IOPF could be handled, SVA
should continue to work.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
drivers/iommu/intel/iommu.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
Comments
> From: Lu Baolu <baolu.lu@linux.intel.com> > Sent: Thursday, March 9, 2023 10:57 AM > > @@ -4650,7 +4650,18 @@ static int intel_iommu_enable_sva(struct device > *dev) > if (!(iommu->flags & VTD_FLAG_SVM_CAPABLE)) > return -ENODEV; > > - if (!info->pasid_enabled || !info->pri_enabled || !info->ats_enabled) > + if (!info->pasid_enabled) > + return -EINVAL; > + I think you still want to check ats_enabled even for device specific IOPF.
On 2023/3/16 15:09, Tian, Kevin wrote: >> From: Lu Baolu <baolu.lu@linux.intel.com> >> Sent: Thursday, March 9, 2023 10:57 AM >> >> @@ -4650,7 +4650,18 @@ static int intel_iommu_enable_sva(struct device >> *dev) >> if (!(iommu->flags & VTD_FLAG_SVM_CAPABLE)) >> return -ENODEV; >> >> - if (!info->pasid_enabled || !info->pri_enabled || !info->ats_enabled) >> + if (!info->pasid_enabled) >> + return -EINVAL; >> + > > I think you still want to check ats_enabled even for device specific IOPF. Yeah! Updated. Best regards, baolu
Hi BaoLu, On Thu, 9 Mar 2023 10:56:36 +0800, Lu Baolu <baolu.lu@linux.intel.com> wrote: > Currently enabling SVA requires IOPF support from the IOMMU and device > PCI PRI. However, some devices can handle IOPF by itself without ever > sending PCI page requests nor advertising PRI capability. > > Allow SVA support with IOPF handled either by IOMMU (PCI PRI) or device > driver (device-specific IOPF). As long as IOPF could be handled, SVA > should continue to work. > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > --- > drivers/iommu/intel/iommu.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index 7c2f4bd33582..d2fcab9d8f61 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -4650,7 +4650,18 @@ static int intel_iommu_enable_sva(struct device > *dev) if (!(iommu->flags & VTD_FLAG_SVM_CAPABLE)) > return -ENODEV; > > - if (!info->pasid_enabled || !info->pri_enabled || > !info->ats_enabled) > + if (!info->pasid_enabled) > + return -EINVAL; > + > + /* > + * Devices having device-specific I/O fault handling should not > + * support PCI/PRI. > + */ > + if (!info->pri_supported) > + return 0; If you put this check at the very beginning, everything else should it be the same, right? Still feel a little weird that, SVA is tied to PRI for PCI PRI but not for device specific IOPF. > + /* Devices supporting ATS/PRI should have it enabled. */ > + if (!info->pri_enabled || !info->ats_enabled) > return -EINVAL; > > ret = iopf_queue_add_device(iommu->iopf_queue, dev); Thanks, Jacob
On 3/21/23 12:00 AM, Jacob Pan wrote: > Hi BaoLu, Hi Jacob, > > On Thu, 9 Mar 2023 10:56:36 +0800, Lu Baolu<baolu.lu@linux.intel.com> > wrote: > >> Currently enabling SVA requires IOPF support from the IOMMU and device >> PCI PRI. However, some devices can handle IOPF by itself without ever >> sending PCI page requests nor advertising PRI capability. >> >> Allow SVA support with IOPF handled either by IOMMU (PCI PRI) or device >> driver (device-specific IOPF). As long as IOPF could be handled, SVA >> should continue to work. >> >> Signed-off-by: Lu Baolu<baolu.lu@linux.intel.com> >> --- >> drivers/iommu/intel/iommu.c | 13 ++++++++++++- >> 1 file changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c >> index 7c2f4bd33582..d2fcab9d8f61 100644 >> --- a/drivers/iommu/intel/iommu.c >> +++ b/drivers/iommu/intel/iommu.c >> @@ -4650,7 +4650,18 @@ static int intel_iommu_enable_sva(struct device >> *dev) if (!(iommu->flags & VTD_FLAG_SVM_CAPABLE)) >> return -ENODEV; >> >> - if (!info->pasid_enabled || !info->pri_enabled || >> !info->ats_enabled) >> + if (!info->pasid_enabled) >> + return -EINVAL; >> + >> + /* >> + * Devices having device-specific I/O fault handling should not >> + * support PCI/PRI. >> + */ >> + if (!info->pri_supported) >> + return 0; > If you put this check at the very beginning, everything else should it be > the same, right? Even for device specific IOPF, PASID/ATS are still required on the IOMMU side. > > Still feel a little weird that, SVA is tied to PRI for PCI PRI but not for > device specific IOPF. PCI PRI and device specific IOPF *should* be equivalent. But the IOMMU side has no means to check the capability of device-specific IOPF. Therefore, IOMMU can only default that if the device driver enables SVA on a non-PRI device, it will handle IOPF in its own way. Best regards, baolu
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 7c2f4bd33582..d2fcab9d8f61 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -4650,7 +4650,18 @@ static int intel_iommu_enable_sva(struct device *dev) if (!(iommu->flags & VTD_FLAG_SVM_CAPABLE)) return -ENODEV; - if (!info->pasid_enabled || !info->pri_enabled || !info->ats_enabled) + if (!info->pasid_enabled) + return -EINVAL; + + /* + * Devices having device-specific I/O fault handling should not + * support PCI/PRI. + */ + if (!info->pri_supported) + return 0; + + /* Devices supporting ATS/PRI should have it enabled. */ + if (!info->pri_enabled || !info->ats_enabled) return -EINVAL; ret = iopf_queue_add_device(iommu->iopf_queue, dev);