All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: iommu@lists.linux.dev, joro@8bytes.org,
	suravee.suthikulpanit@amd.com, wei.huang2@amd.com,
	jsnitsel@redhat.com
Subject: Re: [PATCH v2 13/16] iommu/amd: Introduce iommu_dev_data.flags to track device capabilities
Date: Fri, 28 Jul 2023 11:38:40 -0300	[thread overview]
Message-ID: <ZMPS8IGzwSWdnNWv@ziepe.ca> (raw)
In-Reply-To: <20230728053609.165183-14-vasant.hegde@amd.com>

On Fri, Jul 28, 2023 at 05:36:06AM +0000, Vasant Hegde wrote:
> Currently we use struct iommu_dev_data.iommu_v2 to keep track of the device
> ATS, PRI, and PASID capabilities. But these capabilities can be enabled
> independently (except PRI requires ATS support). Hence, replace
> the iommu_v2 variable with a flags variable, which keep track of the device
> capabilities.
>
> Device PRI/PASID is shared between PF and any associated VFs (See commit
> 9bf49e36d718 ("PCI/ATS: Handle sharing of PF PRI Capability with
> all VFs")). Hence use pci_pri_supported() and pci_pasid_features()
> instead of pci_find_ext_capability() to check device PRI/PASID support.
> 
> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
> ---
>  drivers/iommu/amd/amd_iommu_types.h |  2 +-
>  drivers/iommu/amd/iommu.c           | 39 +++++++++++++++--------------
>  2 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
> index 321d361dfb60..57c74870b17f 100644
> --- a/drivers/iommu/amd/amd_iommu_types.h
> +++ b/drivers/iommu/amd/amd_iommu_types.h
> @@ -821,7 +821,7 @@ struct iommu_dev_data {
>  	struct protection_domain *domain; /* Domain the device is bound to */
>  	struct device *dev;
>  	u16 devid;			  /* PCI Device ID */
> -	bool iommu_v2;			  /* Device can make use of IOMMUv2 */
> +	u32 flags;			  /* Holds AMD_IOMMU_DEVICE_FLAG_<*> */
>  	int  ats_qdep;
>  	bool ats_enabled;		  /* ATS state */
>  	bool pri_tlp;			  /* PASID TLB required for
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index e67c6fae452c..7f67e8991949 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -314,24 +314,25 @@ static struct iommu_group *acpihid_device_group(struct device *dev)
>  	return entry->group;
>  }
>  
> -static bool pci_iommuv2_capable(struct pci_dev *pdev)
> +static inline bool pdev_pasid_supported(struct iommu_dev_data *dev_data)
>  {
> -	static const int caps[] = {
> -		PCI_EXT_CAP_ID_PRI,
> -		PCI_EXT_CAP_ID_PASID,
> -	};
> -	int i, pos;
> +	return (dev_data->flags & AMD_IOMMU_DEVICE_FLAG_PASID_SUP);
> +}
>  
> -	if (!pci_ats_supported(pdev))
> -		return false;
> +static u32 pdev_get_caps(struct pci_dev *pdev)
> +{
> +	u32 flags = 0;
>  
> -	for (i = 0; i < 2; ++i) {
> -		pos = pci_find_ext_capability(pdev, caps[i]);
> -		if (pos == 0)
> -			return false;
> -	}
> +	if (pci_ats_supported(pdev))
> +		flags |= AMD_IOMMU_DEVICE_FLAG_ATS_SUP;
>  
> -	return true;
> +	if (pci_pri_supported(pdev))
> +		flags |= AMD_IOMMU_DEVICE_FLAG_PRI_SUP;
> +
> +	if (pci_pasid_features(pdev) >= 0)
> +		flags |= AMD_IOMMU_DEVICE_FLAG_PASID_SUP;
> +
> +	return flags;
>  }
>  
>  /*
> @@ -391,8 +392,8 @@ static int iommu_init_device(struct amd_iommu *iommu, struct device *dev)
>  	 * it'll be forced to go into translation mode.
>  	 */
>  	if ((iommu_default_passthrough() || !amd_iommu_force_isolation) &&
> -	    dev_is_pci(dev) && pci_iommuv2_capable(to_pci_dev(dev))) {
> -		dev_data->iommu_v2 = amd_iommu_gt_ppr_supported();
> +	    dev_is_pci(dev) && amd_iommu_gt_ppr_supported()) {
> +		dev_data->flags = pdev_get_caps(to_pci_dev(dev));
>  	}

This is even more confusing now. Why would the flags rely on policy knobs??

> @@ -1843,7 +1844,7 @@ static int attach_device(struct device *dev,
>  			goto out;
>  		}
>  
> -		if (dev_data->iommu_v2) {
> +		if (pdev_pasid_supported(dev_data)) {
>  			if (pdev_pri_ats_enable(pdev) != 0)
>  				goto out;

ATS should be usuable without PASID support. ATS on a RID is perfectly
valid and is being used in the real world.
  
> @@ -1909,7 +1910,7 @@ static void detach_device(struct device *dev)
>  	if (!dev_is_pci(dev))
>  		goto out;
>  
> -	if (domain->flags & PD_IOMMUV2_MASK && dev_data->iommu_v2)
> +	if (domain->flags & PD_IOMMUV2_MASK && pdev_pasid_supported(dev_data))
>  		pdev_iommuv2_disable(to_pci_dev(dev));
>  	else if (dev_data->ats_enabled)
>  		pci_disable_ats(to_pci_dev(dev));
> @@ -2464,7 +2465,7 @@ static int amd_iommu_def_domain_type(struct device *dev)
>  	 *    and require remapping.
>  	 *  - SNP is enabled, because it prohibits DTE[Mode]=0.
>  	 */
> -	if (dev_data->iommu_v2 &&
> +	if (pdev_pasid_supported(dev_data) &&
>  	    !cc_platform_has(CC_ATTR_MEM_ENCRYPT) &&
>  	    !amd_iommu_snp_en) {
>  		return IOMMU_DOMAIN_IDENTITY;

This looks like a mess that needs fixing. PASID support should never
be a trigger for an IDENTITY default domain.

If GPUs are broken then match their PCI ID's and do the workaround
only for them.

Jason

  reply	other threads:[~2023-07-28 14:38 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-28  5:35 [PATCH v2 00/16] iommu/amd: SVA Support (Part 1) - cleanup/refactoring Vasant Hegde
2023-07-28  5:35 ` [PATCH v2 01/16] iommu/amd: Remove unused amd_io_pgtable.pt_root variable Vasant Hegde
2023-07-28 13:17   ` Jason Gunthorpe
2023-07-28  5:35 ` [PATCH v2 02/16] iommu/amd: Consolidate timeout pre-define to amd_iommu_type.h Vasant Hegde
2023-07-28 13:48   ` Jason Gunthorpe
2023-07-28  5:35 ` [PATCH v2 03/16] iommu/amd: Consolidate logic to allocate protection domain Vasant Hegde
2023-07-28 13:49   ` Jason Gunthorpe
2023-07-28  5:35 ` [PATCH v2 04/16] iommu/amd: Refactor protection domain allocation code Vasant Hegde
2023-07-28 13:53   ` Jason Gunthorpe
2023-07-31  6:30     ` Vasant Hegde
2023-07-31 12:03       ` Jason Gunthorpe
2023-07-28  5:35 ` [PATCH v2 05/16] iommu/amd/iommu_v2: Use protection_domain in struct device_state Vasant Hegde
2023-07-28 14:00   ` Jason Gunthorpe
2023-07-28  5:35 ` [PATCH v2 06/16] iommu/amd: Introduce helper functions for managing GCR3 table Vasant Hegde
2023-07-28 14:09   ` Jason Gunthorpe
2023-07-31 10:40     ` Vasant Hegde
2023-07-28  5:36 ` [PATCH v2 07/16] iommu/amd: Use struct protection_domain in helper functions Vasant Hegde
2023-07-28 14:10   ` Jason Gunthorpe
2023-07-28  5:36 ` [PATCH v2 08/16] iommu/amd: Do not set amd_iommu_pgtable in pass-through mode Vasant Hegde
2023-07-28 14:11   ` Jason Gunthorpe
2023-07-31  6:35     ` Vasant Hegde
2023-07-28  5:36 ` [PATCH v2 09/16] iommu/amd: Miscellaneous clean up when free domain Vasant Hegde
2023-07-28 14:13   ` Jason Gunthorpe
2023-07-31  9:39     ` Vasant Hegde
2023-07-28  5:36 ` [PATCH v2 10/16] iommu/amd: Modify logic for checking GT and PPR features Vasant Hegde
2023-07-28 14:24   ` Jason Gunthorpe
2023-07-31 11:51     ` Vasant Hegde
2023-07-28  5:36 ` [PATCH v2 11/16] iommu/amd: Rename ats related variables Vasant Hegde
2023-07-28 14:27   ` Jason Gunthorpe
2023-07-31  9:15     ` Vasant Hegde
2023-07-28  5:36 ` [PATCH v2 12/16] iommu/amd: Add support for different types of PPR handler Vasant Hegde
2023-07-28 14:31   ` Jason Gunthorpe
2023-07-31  8:02     ` Vasant Hegde
2023-07-31 12:11       ` Jason Gunthorpe
2023-07-31 12:28         ` Vasant Hegde
2023-07-28  5:36 ` [PATCH v2 13/16] iommu/amd: Introduce iommu_dev_data.flags to track device capabilities Vasant Hegde
2023-07-28 14:38   ` Jason Gunthorpe [this message]
2023-07-31  7:57     ` Vasant Hegde
2023-07-31 12:08       ` Jason Gunthorpe
2023-08-04  6:40         ` Vasant Hegde
2023-07-28  5:36 ` [PATCH v2 14/16] iommu/amd: Enable device ATS/PASID/PRI capabilities independently Vasant Hegde
2023-07-28 14:40   ` Jason Gunthorpe
2023-07-28  5:36 ` [PATCH v2 15/16] iommu/amd: Initialize iommu_device->max_pasids Vasant Hegde
2023-07-28 14:46   ` Jason Gunthorpe
2023-07-31  7:03     ` Vasant Hegde
2023-07-31 12:07       ` Jason Gunthorpe
2023-07-31 16:04         ` Vasant Hegde
2023-07-28  5:36 ` [PATCH v2 16/16] iommu/amd: Simplify amd_iommu_device_info() Vasant Hegde
2023-07-28 14:47   ` Jason Gunthorpe

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=ZMPS8IGzwSWdnNWv@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=jsnitsel@redhat.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=wei.huang2@amd.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.