From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: Jonathan Cameron
<Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org
Subject: Re: Preferred method to detect if a device is behind an enabled iommu.
Date: Thu, 1 Feb 2018 12:49:24 +0000 [thread overview]
Message-ID: <433fcde8-bcd6-9ab0-ffc5-baf0a6634379@arm.com> (raw)
In-Reply-To: <20180201101821.00006a16-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On 01/02/18 10:18, Jonathan Cameron wrote:
> Hi All,
>
> We have a crypto accelerator which needs to have a few different settings
> depending on whether or not the SMMUv3 is enabled and translating addresses
> or not.
>
> https://marc.info/?l=linux-crypto-vger&m=151732626428206&w=2
>
> 1) A quirk of the hardware revision means we need to turn some elements
> off if the iommu is enabled.
> 2) The device has certain cache related settings that means it needs to know
> if it is dealing with VAs or PAs.
>
> Current approach is to see if the iommu_group is set in struct device.
>
> We could fine one instance of another driver doing this and copied that,
> (drivers/dma/rcar-dmac.c)
> but the precedence is weak enough that confirmation would be good.
> So whilst it 'works' the question is whether it is safe in general
> and whether there is a better way.
The presence of a group alone is not sufficient, as it only tells you
that the device is associated with an IOMMU in some way (including VFIO
no-iommu mode where said IOMMU isn't even real).
To detect whether translation is active, I think the best way right now
would be to first call iommu_get_domain_for_dev() to see whether the
device is actually attached to a domain, then if so check the domain
type for the __IOMMU_DOMAIN_PAGING flag to confirm if it represents a
translation context rather than a bypass one.
It might be reasonable to propose wrapping that up in an IOMMU API (or
possibly DMA API, as appropriate) helper, as there are certainly other
drivers doing various degrees of this sort of thing for various reasons
(to the point where we currently have to accommodate rather nonsensical
iova_to_phys() calls on identity domains).
Robin.
next prev parent reply other threads:[~2018-02-01 12:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 10:18 Preferred method to detect if a device is behind an enabled iommu Jonathan Cameron
[not found] ` <20180201101821.00006a16-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2018-02-01 12:49 ` Robin Murphy [this message]
[not found] ` <433fcde8-bcd6-9ab0-ffc5-baf0a6634379-5wv7dgnIgG8@public.gmane.org>
2018-02-01 13:25 ` Jonathan Cameron
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=433fcde8-bcd6-9ab0-ffc5-baf0a6634379@arm.com \
--to=robin.murphy-5wv7dgnigg8@public.gmane.org \
--cc=Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.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).