linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	joro@8bytes.org, will@kernel.org
Cc: vivek.gautam@arm.com, guohanjun@huawei.com,
	Zhou Wang <wangzhou1@hisilicon.com>,
	linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
	lenb@kernel.org, devicetree@vger.kernel.org,
	Arnd Bergmann <arnd@arndb.de>,
	eric.auger@redhat.com, robh+dt@kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	rjw@rjwysocki.net, shameerali.kolothum.thodi@huawei.com,
	iommu@lists.linux-foundation.org, "Pan,
	Jacob jun" <jacob.jun.pan@intel.com>,
	sudeep.holla@arm.com, robin.murphy@arm.com,
	linux-accelerators@lists.ozlabs.org, baolu.lu@linux.intel.com
Subject: Re: [PATCH v9 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF
Date: Wed, 20 Jan 2021 13:47:25 -0700	[thread overview]
Message-ID: <e14f47bd-1b0c-1905-3bb7-62e1c5b096c7@intel.com> (raw)
In-Reply-To: <20210108145217.2254447-6-jean-philippe@linaro.org>


On 1/8/2021 7:52 AM, Jean-Philippe Brucker wrote:
> The IOPF (I/O Page Fault) feature is now enabled independently from the
> SVA feature, because some IOPF implementations are device-specific and
> do not require IOMMU support for PCIe PRI or Arm SMMU stall.
>
> Enable IOPF unconditionally when enabling SVA for now. In the future, if
> a device driver implementing a uacce interface doesn't need IOPF
> support, it will need to tell the uacce module, for example with a new
> flag.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Zhangfei Gao <zhangfei.gao@linaro.org>
> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> ---
>   drivers/misc/uacce/uacce.c | 32 +++++++++++++++++++++++++-------
>   1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/misc/uacce/uacce.c b/drivers/misc/uacce/uacce.c
> index d07af4edfcac..41ef1eb62a14 100644
> --- a/drivers/misc/uacce/uacce.c
> +++ b/drivers/misc/uacce/uacce.c
> @@ -385,6 +385,24 @@ static void uacce_release(struct device *dev)
>   	kfree(uacce);
>   }
>   
> +static unsigned int uacce_enable_sva(struct device *parent, unsigned int flags)
> +{
> +	if (!(flags & UACCE_DEV_SVA))
> +		return flags;
> +
> +	flags &= ~UACCE_DEV_SVA;
> +
> +	if (iommu_dev_enable_feature(parent, IOMMU_DEV_FEAT_IOPF))
> +		return flags;
> +
> +	if (iommu_dev_enable_feature(parent, IOMMU_DEV_FEAT_SVA)) {
> +		iommu_dev_disable_feature(parent, IOMMU_DEV_FEAT_IOPF);
> +		return flags;
> +	}

Sorry to jump in a bit late on this and not specifically towards the 
intent of this patch. But I'd like to start a discussion on if we want 
to push the iommu dev feature enabling to the device driver itself 
rather than having UACCE control this? Maybe allow the device driver to 
manage the feature bits and UACCE only verify that they are enabled?

 1. The device driver knows what platform it's on and what specific
    feature bits its devices supports. Maybe in the future if there are
    feature bits that's needed on one platform and not on another?
 2. This allows the possibility of multiple uacce device registered to 1
    pci dev, which for a device with asymmetric queues (Intel DSA/idxd
    driver) that is desirable feature. The current setup forces a single
    uacce device per pdev. If additional uacce devs are registered, the
    first removal of uacce device will disable the feature bit for the
    rest of the registered devices. With uacce managing the feature bit,
    it would need to add device context to the parent pdev and ref
    counting. It may be cleaner to just allow device driver to manage
    the feature bits and the driver should have all the information on
    when the feature needs to be turned on and off.

- DaveJ


> +
> +	return flags | UACCE_DEV_SVA;
> +}
> +
>   /**
>    * uacce_alloc() - alloc an accelerator
>    * @parent: pointer of uacce parent device
> @@ -404,11 +422,7 @@ struct uacce_device *uacce_alloc(struct device *parent,
>   	if (!uacce)
>   		return ERR_PTR(-ENOMEM);
>   
> -	if (flags & UACCE_DEV_SVA) {
> -		ret = iommu_dev_enable_feature(parent, IOMMU_DEV_FEAT_SVA);
> -		if (ret)
> -			flags &= ~UACCE_DEV_SVA;
> -	}
> +	flags = uacce_enable_sva(parent, flags);
>   
>   	uacce->parent = parent;
>   	uacce->flags = flags;
> @@ -432,8 +446,10 @@ struct uacce_device *uacce_alloc(struct device *parent,
>   	return uacce;
>   
>   err_with_uacce:
> -	if (flags & UACCE_DEV_SVA)
> +	if (flags & UACCE_DEV_SVA) {
>   		iommu_dev_disable_feature(uacce->parent, IOMMU_DEV_FEAT_SVA);
> +		iommu_dev_disable_feature(uacce->parent, IOMMU_DEV_FEAT_IOPF);
> +	}
>   	kfree(uacce);
>   	return ERR_PTR(ret);
>   }
> @@ -487,8 +503,10 @@ void uacce_remove(struct uacce_device *uacce)
>   	mutex_unlock(&uacce->queues_lock);
>   
>   	/* disable sva now since no opened queues */
> -	if (uacce->flags & UACCE_DEV_SVA)
> +	if (uacce->flags & UACCE_DEV_SVA) {
>   		iommu_dev_disable_feature(uacce->parent, IOMMU_DEV_FEAT_SVA);
> +		iommu_dev_disable_feature(uacce->parent, IOMMU_DEV_FEAT_IOPF);
> +	}
>   
>   	if (uacce->cdev)
>   		cdev_device_del(uacce->cdev, &uacce->dev);

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-01-20 20:49 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08 14:52 [PATCH v9 00/10] iommu: I/O page faults for SMMUv3 Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 01/10] iommu: Remove obsolete comment Jean-Philippe Brucker
2021-01-19 11:11   ` Jonathan Cameron
2021-01-20 17:41     ` Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits Jean-Philippe Brucker
2021-01-19 11:22   ` Jonathan Cameron
2021-01-08 14:52 ` [PATCH v9 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA Jean-Philippe Brucker
2021-01-12  4:31   ` Lu Baolu
2021-01-12  9:16     ` Jean-Philippe Brucker
2021-01-13  2:49       ` Lu Baolu
2021-01-13  8:10         ` Tian, Kevin
2021-01-14 16:41           ` Jean-Philippe Brucker
2021-01-16  3:54             ` Lu Baolu
2021-01-18  6:54               ` Tian, Kevin
2021-01-19 10:16                 ` Jean-Philippe Brucker
2021-01-20  1:57                   ` Lu Baolu
2021-01-08 14:52 ` [PATCH v9 04/10] iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-11  3:29   ` Zhangfei Gao
2021-01-19 12:27   ` Jonathan Cameron
2021-01-20 17:42     ` Jean-Philippe Brucker
2021-01-20 20:47   ` Dave Jiang [this message]
2021-01-22 11:53     ` Zhou Wang
2021-01-22 15:43       ` Dave Jiang
2021-01-08 14:52 ` [PATCH v9 06/10] iommu: Add a page fault handler Jean-Philippe Brucker
2021-01-19 13:38   ` Jonathan Cameron
2021-01-20 17:43     ` Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure Jean-Philippe Brucker
2021-01-19 13:51   ` Jonathan Cameron
2021-01-08 14:52 ` [PATCH v9 08/10] dt-bindings: document stall property for IOMMU masters Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 09/10] ACPI/IORT: Enable stall support for platform devices Jean-Philippe Brucker
2021-01-08 14:52 ` [PATCH v9 10/10] iommu/arm-smmu-v3: Add " Jean-Philippe Brucker
2021-01-19 17:28   ` Robin Murphy
2021-01-20 17:55     ` Jean-Philippe Brucker
2021-01-11  3:26 ` [PATCH v9 00/10] iommu: I/O page faults for SMMUv3 Zhangfei Gao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e14f47bd-1b0c-1905-3bb7-62e1c5b096c7@intel.com \
    --to=dave.jiang@intel.com \
    --cc=arnd@arndb.de \
    --cc=baolu.lu@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=eric.auger@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=lenb@kernel.org \
    --cc=linux-accelerators@lists.ozlabs.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=sudeep.holla@arm.com \
    --cc=vivek.gautam@arm.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=will@kernel.org \
    --cc=zhangfei.gao@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).