[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABQgh9EeKtYuu+vTTM0fwaKrLxdyC355MQxN8o8_OL9Y1NkE8A@mail.gmail.com>
Date: Tue, 15 Oct 2024 11:19:33 +0800
From: Zhangfei Gao <zhangfei.gao@...aro.org>
To: Lu Baolu <baolu.lu@...ux.intel.com>
Cc: Jason Gunthorpe <jgg@...pe.ca>, Kevin Tian <kevin.tian@...el.com>, Joerg Roedel <joro@...tes.org>,
Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
Jean-Philippe Brucker <jean-philippe@...aro.org>, Nicolin Chen <nicolinc@...dia.com>,
Yi Liu <yi.l.liu@...el.com>, Jacob Pan <jacob.jun.pan@...ux.intel.com>,
Joel Granados <j.granados@...sung.com>, iommu@...ts.linux.dev,
virtualization@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
Subject: Re: [PATCH v8 07/10] iommufd: Fault-capable hwpt attach/detach/replace
Hi, Baolu
On Tue, 2 Jul 2024 at 14:39, Lu Baolu <baolu.lu@...ux.intel.com> wrote:
>
> Add iopf-capable hw page table attach/detach/replace helpers. The pointer
> to iommufd_device is stored in the domain attachment handle, so that it
> can be echo'ed back in the iopf_group.
>
> The iopf-capable hw page tables can only be attached to devices that
> support the IOMMU_DEV_FEAT_IOPF feature. On the first attachment of an
> iopf-capable hw_pagetable to the device, the IOPF feature is enabled on
> the device. Similarly, after the last iopf-capable hwpt is detached from
> the device, the IOPF feature is disabled on the device.
>
> The current implementation allows a replacement between iopf-capable and
> non-iopf-capable hw page tables. This matches the nested translation use
> case, where a parent domain is attached by default and can then be
> replaced with a nested user domain with iopf support.
>
> Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
> Reviewed-by: Kevin Tian <kevin.tian@...el.com>
> ---
> drivers/iommu/iommufd/iommufd_private.h | 41 +++++
> drivers/iommu/iommufd/device.c | 7 +-
> drivers/iommu/iommufd/fault.c | 190 ++++++++++++++++++++++++
> 3 files changed, 235 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/iommufd/fault.c b/drivers/iommu/iommufd/fault.c
> index 68ff94671d48..4934ae572638 100644
> --- a/drivers/iommu/iommufd/fault.c
> +++ b/drivers/iommu/iommufd/fault.c
> @@ -8,6 +8,7 @@
> #include <linux/module.h>
> #include <linux/mutex.h>
> #include <linux/iommufd.h>
> +#include <linux/pci.h>
> #include <linux/poll.h>
> #include <linux/anon_inodes.h>
> #include <uapi/linux/iommufd.h>
> @@ -15,6 +16,195 @@
> #include "../iommu-priv.h"
> #include "iommufd_private.h"
>
> +static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
> +{
> + struct device *dev = idev->dev;
> + int ret;
> +
> + /*
> + * Once we turn on PCI/PRI support for VF, the response failure code
> + * should not be forwarded to the hardware due to PRI being a shared
> + * resource between PF and VFs. There is no coordination for this
> + * shared capability. This waits for a vPRI reset to recover.
> + */
> + if (dev_is_pci(dev) && to_pci_dev(dev)->is_virtfn)
> + return -EINVAL;
I am using the SMMUv3 stall feature, and need to forward this to hardware,
And now I am hacking to comment this check.
Any suggestions?
> +
> + mutex_lock(&idev->iopf_lock);
> + /* Device iopf has already been on. */
> + if (++idev->iopf_enabled > 1) {
> + mutex_unlock(&idev->iopf_lock);
> + return 0;
> + }
> +
> + ret = iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_IOPF);
> + if (ret)
> + --idev->iopf_enabled;
> + mutex_unlock(&idev->iopf_lock);
Also iommu_dev_enable_feature(idev->dev, IOMMU_DEV_FEAT_SVA); is required
In thinking how to add it properly.
Thanks
Powered by blists - more mailing lists