From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Baolu Lu <baolu.lu@linux.intel.com>,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
gerald.schaefer@linux.ibm.com, schnelle@linux.ibm.com
Cc: hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com,
svens@linux.ibm.com, borntraeger@linux.ibm.com,
farman@linux.ibm.com, clegoate@redhat.com, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 5/6] iommu: document missing def_domain_type return
Date: Tue, 10 Dec 2024 11:26:27 -0500 [thread overview]
Message-ID: <0e80948b-7593-4b59-bb77-2f78f00ad2c3@linux.ibm.com> (raw)
In-Reply-To: <3db6f346-0cb4-41f7-b532-91bcb0265849@linux.intel.com>
On 12/9/24 9:57 PM, Baolu Lu wrote:
> On 12/10/24 03:24, Matthew Rosato wrote:
>> In addition to IOMMU_DOMAIN_DMA, def_domain_type can also return
>> IOMMU_DOMAIN_DMA_FQ when applicable, else flush queues will never be
>> used.
>>
>> Signed-off-by: Matthew Rosato<mjrosato@linux.ibm.com>
>> ---
>> include/linux/iommu.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index 05279109c732..d0da1918d2de 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -585,6 +585,7 @@ iommu_copy_struct_from_full_user_array(void *kdst, size_t kdst_entry_size,
>> * @def_domain_type: device default domain type, return value:
>> * - IOMMU_DOMAIN_IDENTITY: must use an identity domain
>> * - IOMMU_DOMAIN_DMA: must use a dma domain
>> + * - IOMMU_DOMAIN_DMA_FQ: dma domain with batch invalidation
>
> In which case must an iommu driver return IOMMU_DOMAIN_DMA_FQ?
>
> The flush queue is a policy of "when and how to synchronize the IOTLB"
> in dma-iommu.c. The iommu driver actually has no need to understand such
> policy.
If you look ahead to the next patch where I implement def_domain_type for s390, I found that if I only ever return IOMMU_DOMAIN_DMA from ops->def_domain_type then when go through iommu_dma_init_domain() we will never call iommu_dma_init_fq() regardless of IOMMU_CAP_DEFERRED_FLUSH because of the if (domain->type == IOMMU_DOMAIN_DMA_FQ) check. So something isn't right here.
It looks to me like the following is happening:
We first have the iommu_def_domain_type set in iommu_subsys_init or via one of the set_default routines, e.g.:
if (!iommu_default_passthrough() && !iommu_dma_strict)
iommu_def_domain_type = IOMMU_DOMAIN_DMA_FQ;
But when we arrive at iommu_group_alloc_default_domain()...
if we have no ops->def_domain_type() defined we will call __iommu_group_alloc_default_domain using what is in iommu_def_domain_type, which could be IOMMU_DOMAIN_DMA, IOMMU_DOMAIN_DMA_FQ or IOMMU_DOMAIN_IDENTITY based on strict/passthrough settings. Testing an s390 scenario today without this series applied, we will call __iommu_group_alloc_default_domain with IOMMU_DOMAIN_DMA_FQ, as long as iommu.strict/passthrough is not specified, so then later in dma-iommu:iommu_dma_init_domain() we can use FQ based on IOMMU_CAP_DEFERRED_FLUSH.
but once we add ops->def_domain_type() then we end up calling iommu_group_alloc_default_domain() with a req_type == the return value from ops->def_domain_type(), which by the current definition can only be IOMMU_DOMAIN_DMA or IOMMU_DOMAIN_IDENTITY. We will then call __iommu_group_alloc_default_domain with that req_type; so without this patch + the DMA_FQ path in patch 6 we would always end up allocating IOMMU_DOMAIN_DMA instead of IOMMU_DOMAIN_DMA_FQ by default, so when we arrive at dma:iommu_dma_init_domain() we won't check for IOMMU_CAP_DEFERRED_FLUSH because of the type.
So unless I'm missing something I think either we have to
1) be more flexible in what ops->default_domain_type() is allowed to return as this patch does
or
2) iommu core needs to look at the return from ops->default_domain_type() and decide whether it's OK to convert IOMMU_DOMAIN_DMA->IOMMU_DOMAIN_DMA_FQ based on strict setting. This removes the decision from the individual drivers and dma-iommu can later decide whether or not to use it or not based on IOMMU_CAP_DEFERRED_FLUSH? But would also affect other users of def_domain_type() today that perhaps did not want DMA_FQ? Unsure. What I mean is something like (untested):
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 6bdede4177ff..275daa7f819d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1744,9 +1744,11 @@ static int iommu_get_def_domain_type(struct iommu_group *group,
*/
type = ops->default_domain->type;
} else {
- if (ops->def_domain_type)
+ if (ops->def_domain_type) {
type = ops->def_domain_type(dev);
- else
+ if (type == IOMMU_DOMAIN_DMA && !iommu_dma_strict)
+ type = IOMMU_DOMAIN_DMA_FQ;
+ } else
return cur_type;
}
if (!type || cur_type == type)
next prev parent reply other threads:[~2024-12-10 16:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 19:23 [PATCH 0/6] iommu/s390: add support for IOMMU passthrough Matthew Rosato
2024-12-09 19:23 ` [PATCH 1/6] s390/pci: check for relaxed translation capability Matthew Rosato
2024-12-09 19:23 ` [PATCH 2/6] s390: enable ARCH_HAS_PHYS_TO_DMA Matthew Rosato
2024-12-10 4:33 ` Christoph Hellwig
2024-12-10 21:23 ` Matthew Rosato
2024-12-09 19:24 ` [PATCH 3/6] iommu/s390: implement iommu passthrough via identity domain Matthew Rosato
2024-12-09 19:24 ` [PATCH 4/6] iommu: add routine to check strict setting Matthew Rosato
2024-12-09 19:24 ` [PATCH 5/6] iommu: document missing def_domain_type return Matthew Rosato
2024-12-10 2:57 ` Baolu Lu
2024-12-10 16:26 ` Matthew Rosato [this message]
2024-12-10 18:42 ` Robin Murphy
2024-12-10 22:06 ` Matthew Rosato
2024-12-11 18:42 ` Robin Murphy
2024-12-09 19:24 ` [PATCH 6/6] iommu/s390: implement def_domain_type Matthew Rosato
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=0e80948b-7593-4b59-bb77-2f78f00ad2c3@linux.ibm.com \
--to=mjrosato@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=baolu.lu@linux.intel.com \
--cc=borntraeger@linux.ibm.com \
--cc=clegoate@redhat.com \
--cc=farman@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=schnelle@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=will@kernel.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