From: eric.auger@linaro.org (Eric Auger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 6/8] iommu/msi-iommu: iommu_msi_domain
Date: Mon, 2 May 2016 17:48:13 +0200 [thread overview]
Message-ID: <572776BD.2080503@linaro.org> (raw)
In-Reply-To: <20160428162740.28db4b8d@t450s.home>
Hi Alex,
On 04/29/2016 12:27 AM, Alex Williamson wrote:
> On Thu, 28 Apr 2016 08:15:21 +0000
> Eric Auger <eric.auger@linaro.org> wrote:
>
>> This function checks whether
>> - the device belongs to a non default iommu domain
>> - this iommu domain requires the MSI address to be mapped.
>>
>> If those conditions are met, the function returns the iommu domain
>> to be used for mapping the MSI doorbell; else it returns NULL.
>>
>> Signed-off-by: Eric Auger <eric.auger@linaro.org>
>>
>> ---
>>
>> v7 -> v8:
>> - renamed iommu_msi_mapping_desc_to_domain to iommu_msi_domain
>> - the function now takes a struct device *
>> - use DOMAIN_ATTR_MSI_GEOMETRY attribute
>> ---
>> drivers/iommu/msi-iommu.c | 17 +++++++++++++++++
>> include/linux/msi-iommu.h | 14 ++++++++++++++
>> 2 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/iommu/msi-iommu.c b/drivers/iommu/msi-iommu.c
>> index 203e86e..023ff17 100644
>> --- a/drivers/iommu/msi-iommu.c
>> +++ b/drivers/iommu/msi-iommu.c
>> @@ -243,3 +243,20 @@ unlock:
>> }
>> }
>> EXPORT_SYMBOL_GPL(iommu_msi_put_doorbell_iova);
>> +
>> +struct iommu_domain *iommu_msi_domain(struct device *dev)
>> +{
>> + struct iommu_domain *d = iommu_get_domain_for_dev(dev);
>> + struct iommu_domain_msi_geometry msi_geometry;
>> +
>> + if (!d || (d->type == IOMMU_DOMAIN_DMA))
>> + return NULL;
>> +
>> + iommu_domain_get_attr(d, DOMAIN_ATTR_MSI_GEOMETRY, &msi_geometry);
>> + if (!msi_geometry.programmable)
>
> It feels like we're conflating ideas with using the "programmable" flag
> in this way. AIUI the IOMMU API consumer is supposed to see the
> invalid MSI geometry with the programmable feature set and know to call
> iommu_msi_set_aperture(). Looking for the msi_cookie would tell us if
> that had been done, but that doesn't tell us if it should have been
> done. iommu_msi_msg_pa_to_va() handles this later, if we return
> NULL here that function returns success otherwise it goes on to fail if
> the iova or msi cookie is not set. So really what we're trying to flag
> is that the MSI geometry participates in the IOMMU-MSI API you've
> created and we should pick a feature name that says that rather than
> something as vague a "programmable". Perhaps simply iommu_msi_api
> rather than programmable.
Yes I had the same questioning too when I wrote this code. So if my
understanding is correct we would have
- programmable: tells whether the MSI range is fixed or pogrammable and,
- mapping_required (new boolean field): indicating whether MSIs need to
be mapped in the IOMMU
>
> BTW, I don't see that you ever set aperture_start/end once
> iommu_msi_set_aperture() has been called. It seems like doing so would
> add some consistency to that MSI geometry attribute.
Indeed currently I mentionned:
/* In case the aperture is programmable, start/end are set to 0 */
If I set start/end in iommu_msi_set_aperture then I think I should also
return the actual values in iommu_domain_get_attr. I thought the extra
care to handle the possible race between the set_aperture (msi_iommu)
and the get_attr (iommu) was maybe not worth the benefits:
is_aperture_set is not visible to get_attr so I would be forced to
introduce a mutex at iommu_domain level or call an msi-iommu function
from iommu implementation. So I preferred to keep start/end as read-only
info initialized by the iommu driver.
>
> Nice series overall. Thanks,
Thanks
Eric
>
> Alex
>
>> + return NULL;
>> +
>> + return d;
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_msi_domain);
>> +
>> diff --git a/include/linux/msi-iommu.h b/include/linux/msi-iommu.h
>> index 1cd115f..114bd69 100644
>> --- a/include/linux/msi-iommu.h
>> +++ b/include/linux/msi-iommu.h
>> @@ -81,6 +81,15 @@ int iommu_msi_get_doorbell_iova(struct iommu_domain *domain,
>> */
>> void iommu_msi_put_doorbell_iova(struct iommu_domain *domain, phys_addr_t addr);
>>
>> +/**
>> + * iommu_msi_domain: in case the device is upstream to an IOMMU and this IOMMU
>> + * translates the MSI transaction, returns the iommu domain the MSI doorbell
>> + * address must be mapped in; else returns NULL.
>> + *
>> + * @dev: device handle
>> + */
>> +struct iommu_domain *iommu_msi_domain(struct device *dev);
>> +
>> #else
>>
>> static inline int
>> @@ -100,5 +109,10 @@ static inline int iommu_msi_get_doorbell_iova(struct iommu_domain *domain,
>> static inline void iommu_msi_put_doorbell_iova(struct iommu_domain *domain,
>> phys_addr_t addr) {}
>>
>> +static inline struct iommu_domain *iommu_msi_domain(struct device *dev)
>> +{
>> + return NULL;
>> +}
>> +
>> #endif /* CONFIG_IOMMU_MSI */
>> #endif /* __MSI_IOMMU_H */
>
next prev parent reply other threads:[~2016-05-02 15:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 8:15 [PATCH v8 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 1/3: iommu changes Eric Auger
2016-04-28 8:15 ` [PATCH v8 1/8] iommu: Add iommu_domain_msi_geometry and DOMAIN_ATTR_MSI_GEOMETRY Eric Auger
2016-04-28 8:15 ` [PATCH v8 2/8] iommu/arm-smmu: sets the MSI geometry to programmable Eric Auger
2016-04-28 8:15 ` [PATCH v8 3/8] iommu: introduce an msi cookie Eric Auger
2016-04-28 8:15 ` [PATCH v8 4/8] iommu/msi-iommu: initialization Eric Auger
2016-04-28 8:15 ` [PATCH v8 5/8] iommu/msi-iommu: iommu_msi_[get,put]_doorbell_iova Eric Auger
2016-04-28 8:15 ` [PATCH v8 6/8] iommu/msi-iommu: iommu_msi_domain Eric Auger
2016-04-28 22:27 ` Alex Williamson
2016-05-02 15:48 ` Eric Auger [this message]
2016-05-02 20:23 ` Alex Williamson
2016-05-03 12:27 ` Eric Auger
2016-04-28 8:15 ` [PATCH v8 7/8] iommu/msi-iommu: iommu_msi_msg_pa_to_va Eric Auger
2016-04-28 8:15 ` [PATCH v8 8/8] iommu/arm-smmu: get/put the msi cookie Eric Auger
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=572776BD.2080503@linaro.org \
--to=eric.auger@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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).