From: Robin Murphy <robin.murphy@arm.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>,
Jason Gunthorpe <jgg@nvidia.com>
Cc: Baolu Lu <baolu.lu@linux.intel.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Gerd Bayer <gbayer@linux.ibm.com>,
iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Wenjia Zhang <wenjia@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
linux-s390@vger.kernel.org, borntraeger@linux.ibm.com,
hca@linux.ibm.com, gor@linux.ibm.com,
gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
svens@linux.ibm.com, linux-kernel@vger.kernel.org,
Julian Ruess <julianr@linux.ibm.com>
Subject: Re: [PATCH v2 4/7] iommu: Let iommu.strict override ops->def_domain_type
Date: Mon, 28 Nov 2022 16:56:39 +0000 [thread overview]
Message-ID: <815278cc-7fad-1657-c07a-e9825f137e5c@arm.com> (raw)
In-Reply-To: <52fe7769ca5b66523c2c93c7d46ebc17dc144aca.camel@linux.ibm.com>
On 2022-11-28 15:54, Niklas Schnelle wrote:
> On Mon, 2022-11-28 at 09:29 -0400, Jason Gunthorpe wrote:
>> On Mon, Nov 28, 2022 at 12:10:39PM +0100, Niklas Schnelle wrote:
>>> On Thu, 2022-11-17 at 09:55 +0800, Baolu Lu wrote:
>>>> On 2022/11/17 1:16, Niklas Schnelle wrote:
>>>>> When iommu.strict=1 is set or iommu_set_dma_strict() was called we
>>>>> should use IOMMU_DOMAIN_DMA irrespective of ops->def_domain_type.
>>>>>
>>>>> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
>>>>> ---
>>>>> drivers/iommu/iommu.c | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>>>> index 65a3b3d886dc..d9bf94d198df 100644
>>>>> --- a/drivers/iommu/iommu.c
>>>>> +++ b/drivers/iommu/iommu.c
>>>>> @@ -1562,6 +1562,9 @@ static int iommu_get_def_domain_type(struct device *dev)
>>>>> {
>>>>> const struct iommu_ops *ops = dev_iommu_ops(dev);
>>>>>
>>>>> + if (iommu_dma_strict)
>>>>> + return IOMMU_DOMAIN_DMA;
>>>>
>>>> If any quirky device must work in IOMMU identity mapping mode, this
>>>> might introduce functional regression. At least for VT-d platforms, some
>>>> devices do require IOMMU identity mapping mode for functionality.
>>>
>>> That's a good point. How about instead of unconditionally returning
>>> IOMMU_DOMAIN_DMA we just do so if the domain type returned by ops-
>>>> def_domain_type uses a flush queue (i.e. the __IOMMU_DOMAIN_DMA_FQ bit
>>> is set). That way a device that only supports identity mapping gets to
>>> set that but iommu_dma_strict at least always prevents use of an IOVA
>>> flush queue.
>>
>> I would prefer we create some formal caps in iommu_ops to describe
>> whatever it is you are trying to do.
>>
>> Jason
>
> I agree that there is currently a lack of distinction between what
> domain types can be used (capability) and which should be used as
> default (iommu.strict=<x>, iommu_set_...(), CONFIG_IOMMU_DEFAULT_DMA,
> ops->def_domain_type.).
As far as I'm concerned, the purpose of .def_domain_type is really just
for quirks where the device needs an identity mapping, based on
knowledge that tends to be sufficiently platform-specific that we prefer
to delegate it to drivers. What apple-dart is doing is really just a
workaround for not being to indicate per-instance domain type support at
the point of the .domain_alloc call, and IIRC what mtk_iommu_v1 is doing
is a horrible giant hack around the arch/arm DMA ops that don't
understand IOMMU groups. Both of those situations are on the cards to be
cleaned up, so don't take too much from them.
> My case though is about the latter which I think has some undocumented
> and surprising precedences built in at the moment. With this series we
> can use all of IOMMU_DOMAIN_DMA(_FQ, _SQ) on any PCI device but we want
> to default to either IOMMU_DOMAIN_DMA_FQ or IOMMU_DOMAIN_SQ based on
> whether we're running in a paging hypervisor (z/VM or KVM) to get the
> best performance. From a semantic point of view I felt that this is a
> good match for ops->def_domain_type in that we pick a default but it's
> still possible to change the domain type e.g. via sysfs. Now this had
> the problem that ops->def_domain_type would cause IOMMU_DOMAIN_DMA_FQ
> to be used even if iommu_set_dma_strict() was called (via
> iommu.strict=1) because there is a undocumented override of ops-
>> def_domain_type over iommu_def_domain_type which I believe comes from
> the mixing of capability and default you also point at.
>
> I think ideally we need two separate mechanism to determine which
> domain types can be used for a particular device (capability) and for
> which one to default to with the latter part having a clear precedence
> between the options. Put together I think iommu.strict=1 should
> override a device's preference (ops->def_domain_type) and
> CONFIG_IOMMU_DEFAULT_DMA to use IOMMU_DOMAIN_DMA but of course only if
> the device is capable of that. Does that sound reasonable?
That sounds like essentially what we already have, though. The current
logic should be thus:
1: If the device is untrusted, it gets strict translation, nothing else.
If that won't actually work, tough.
2: If .def_domain_type returns a specific type, it is because any other
type will not work correctly at all, so we must use that.
3: Otherwise, we compute the user's preferred default type based on
kernel config and command line options.
4: Then we determine whether the IOMMU driver actually supports that
type, by trying to allocate it. If allocation fails and the preferred
type was more relaxed than IOMMU_DOMAIN_DMA, fall back to the stricter
type and try one last time.
AFAICS the distinction and priority of those steps is pretty clear:
1: Core requirements
2: Driver-specific requirements
3: Core preference
4: Driver-specific support
Now, for step 4 we *could* potentially use static capability flags in
place of the "try allocating different things until one succeeds", but
that doesn't change anything other than saving the repetitive
boilerplate in everyone's .domain_alloc implementations. The real moral
of the story here is not to express a soft preference where it will be
interpreted as a hard requirement.
Thanks,
Robin.
next prev parent reply other threads:[~2022-11-28 16:56 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 17:16 [PATCH v2 0/7] iommu/dma: s390 DMA API conversion and optimized IOTLB flushing Niklas Schnelle
2022-11-16 17:16 ` [PATCH v2 1/7] s390/ism: Set DMA coherent mask Niklas Schnelle
2022-11-16 17:16 ` [PATCH v2 2/7] s390/pci: prepare is_passed_through() for dma-iommu Niklas Schnelle
2022-11-16 17:16 ` [PATCH v2 3/7] s390/pci: Use dma-iommu layer Niklas Schnelle
2022-11-28 18:03 ` Robin Murphy
2022-12-19 15:17 ` Niklas Schnelle
2022-11-16 17:16 ` [PATCH v2 4/7] iommu: Let iommu.strict override ops->def_domain_type Niklas Schnelle
2022-11-17 1:55 ` Baolu Lu
2022-11-28 11:10 ` Niklas Schnelle
2022-11-28 13:00 ` Baolu Lu
2022-11-28 13:29 ` Jason Gunthorpe
2022-11-28 15:54 ` Niklas Schnelle
2022-11-28 16:35 ` Jason Gunthorpe
2022-11-28 21:01 ` Robin Murphy
2022-11-29 17:33 ` Jason Gunthorpe
2022-11-29 18:41 ` Robin Murphy
2022-11-29 20:09 ` Jason Gunthorpe
2022-11-30 1:28 ` Baolu Lu
2022-12-05 15:34 ` Niklas Schnelle
2022-12-06 23:09 ` Jason Gunthorpe
2022-12-07 13:18 ` Baolu Lu
2022-12-07 13:23 ` Jason Gunthorpe
2022-12-07 14:18 ` Robin Murphy
2022-12-07 14:30 ` Jason Gunthorpe
2022-11-28 16:56 ` Robin Murphy [this message]
2022-11-16 17:16 ` [PATCH v2 5/7] iommu/dma: Allow a single FQ in addition to per-CPU FQs Niklas Schnelle
2022-11-16 17:16 ` [PATCH v2 6/7] iommu/dma: Enable variable queue size and use larger single queue Niklas Schnelle
2022-11-16 17:16 ` [PATCH v2 7/7] iommu/s390: flush queued IOVAs on RPCIT out of resource indication Niklas Schnelle
2022-11-28 14:52 ` Robin Murphy
2022-11-29 12:00 ` Niklas Schnelle
2022-11-29 12:53 ` Robin Murphy
2022-11-29 14:40 ` Niklas Schnelle
2022-12-02 14:29 ` Niklas Schnelle
2022-12-02 14:42 ` Jason Gunthorpe
2022-12-02 15:12 ` Niklas Schnelle
2022-12-02 15:24 ` Jason Gunthorpe
2022-12-05 18:24 ` Robin Murphy
2022-12-06 10:13 ` Niklas Schnelle
2022-11-29 13:51 ` 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=815278cc-7fad-1657-c07a-e9825f137e5c@arm.com \
--to=robin.murphy@arm.com \
--cc=agordeev@linux.ibm.com \
--cc=baolu.lu@linux.intel.com \
--cc=borntraeger@linux.ibm.com \
--cc=gbayer@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=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=julianr@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=schnelle@linux.ibm.com \
--cc=svens@linux.ibm.com \
--cc=wenjia@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;
as well as URLs for NNTP newsgroup(s).