From: Robin Murphy <robin.murphy@arm.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
iommu@lists.linux-foundation.org
Cc: ashish.kalra@amd.com, vasant.hegde@amd.com
Subject: Re: [PATCH 5/7] iommu: Add domain_type_supported() callback in iommu_ops
Date: Mon, 13 Jun 2022 10:31:33 +0100 [thread overview]
Message-ID: <371cacea-368b-d722-8360-13c229b3112b@arm.com> (raw)
In-Reply-To: <20220613012502.109918-6-suravee.suthikulpanit@amd.com>
On 2022-06-13 02:25, Suravee Suthikulpanit wrote:
> When user requests to change IOMMU domain to a new type, IOMMU generic
> layer checks the requested type against the default domain type returned
> by vendor-specific IOMMU driver.
>
> However, there is only one default domain type, and current mechanism
> does not allow if the requested type does not match the default type.
I don't really follow the reasoning here. If a driver's def_domain_type
callback returns a specific type, it's saying that the device *has* to
have that specific domain type for driver/platform-specific reasons. If
that's not the case, then the driver shouldn't say so in the first place.
> Introducing check_domain_type_supported() callback in iommu_ops,
> which allows IOMMU generic layer to check with vendor-specific IOMMU driver
> whether the requested type is supported. This allows user to request
> types other than the default type.
Note also that you're only adding this in the sysfs path - what about
the "iommu.passthrough=" parameter or CONFIG_IOMMU_DEFAULT_PASSTHROUGH?
AFAICS there shouldn't need to be any core-level changes to support
this. We already have drivers which don't support passthrough at all, so
conditionally not supporting it should be no big deal. What should
happen currently is that def_domain_type returns 0 for "don't care",
then domain_alloc rejects IOMMU_DOMAIN_IDENTITY and and returns NULL, so
iommu_group_alloc_default_domain() falls back to IOMMU_DOMAIN_DMA.
Thanks,
Robin.
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
> drivers/iommu/iommu.c | 13 ++++++++++++-
> include/linux/iommu.h | 2 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index f2c45b85b9fc..4afb956ce083 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1521,6 +1521,16 @@ struct iommu_group *fsl_mc_device_group(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(fsl_mc_device_group);
>
> +static bool iommu_domain_type_supported(struct device *dev, int type)
> +{
> + const struct iommu_ops *ops = dev_iommu_ops(dev);
> +
> + if (ops->domain_type_supported)
> + return ops->domain_type_supported(dev, type);
> +
> + return true;
> +}
> +
> static int iommu_get_def_domain_type(struct device *dev)
> {
> const struct iommu_ops *ops = dev_iommu_ops(dev);
> @@ -2937,7 +2947,8 @@ static int iommu_change_dev_def_domain(struct iommu_group *group,
> * domain the device was booted with
> */
> type = dev_def_dom ? : iommu_def_domain_type;
> - } else if (dev_def_dom && type != dev_def_dom) {
> + } else if (!iommu_domain_type_supported(dev, type) ||
> + (dev_def_dom && type != dev_def_dom)) {
> dev_err_ratelimited(prev_dev, "Device cannot be in %s domain\n",
> iommu_domain_type_str(type));
> ret = -EINVAL;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index fecb72e1b11b..40c47ab15005 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -214,6 +214,7 @@ struct iommu_iotlb_gather {
> * - IOMMU_DOMAIN_IDENTITY: must use an identity domain
> * - IOMMU_DOMAIN_DMA: must use a dma domain
> * - 0: use the default setting
> + * @domain_type_supported: check if the specified domain type is supported
> * @default_domain_ops: the default ops for domains
> * @pgsize_bitmap: bitmap of all possible supported page sizes
> * @owner: Driver module providing these ops
> @@ -252,6 +253,7 @@ struct iommu_ops {
> struct iommu_page_response *msg);
>
> int (*def_domain_type)(struct device *dev);
> + bool (*domain_type_supported)(struct device *dev, int type);
>
> const struct iommu_domain_ops *default_domain_ops;
> unsigned long pgsize_bitmap;
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2022-06-13 9:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 1:24 [PATCH 0/7] iommu/amd: Enforce IOMMU restrictions for SNP-enabled system Suravee Suthikulpanit via iommu
2022-06-13 1:24 ` [PATCH 1/7] iommu/amd: Process all IVHDs before enabling IOMMU features Suravee Suthikulpanit via iommu
2022-06-13 1:24 ` [PATCH 2/7] iommu/amd: Introduce a global variable for tracking SNP enable status Suravee Suthikulpanit via iommu
2022-06-13 1:24 ` [PATCH 3/7] iommu/amd: Introduce function to check SEV-SNP support Suravee Suthikulpanit via iommu
2022-06-13 14:40 ` Suthikulpanit, Suravee via iommu
2022-06-13 1:24 ` [PATCH 4/7] iommu/amd: Set translation valid bit only when IO page tables are in use Suravee Suthikulpanit via iommu
2022-06-13 1:25 ` [PATCH 5/7] iommu: Add domain_type_supported() callback in iommu_ops Suravee Suthikulpanit via iommu
2022-06-13 9:31 ` Robin Murphy [this message]
2022-06-13 14:38 ` Suthikulpanit, Suravee via iommu
2022-06-14 9:51 ` Robin Murphy
2022-06-15 1:25 ` Suthikulpanit, Suravee via iommu
2022-06-13 1:25 ` [PATCH 6/7] iommu/amd: Do not support IOMMU_DOMAIN_IDENTITY when SNP is enabled Suravee Suthikulpanit via iommu
2022-06-13 1:25 ` [PATCH 7/7] iommu/amd: Do not support IOMMUv2 APIs " Suravee Suthikulpanit via iommu
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=371cacea-368b-d722-8360-13c229b3112b@arm.com \
--to=robin.murphy@arm.com \
--cc=ashish.kalra@amd.com \
--cc=iommu@lists.linux-foundation.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox