From: Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
eric.auger-qxv4g6HH51o@public.gmane.org
Cc: julien.grall-5wv7dgnIgG8@public.gmane.org,
jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org,
patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
marc.zyngier-5wv7dgnIgG8@public.gmane.org,
p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [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-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 */
>
WARNING: multiple messages have this Message-ID (diff)
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 */
>
WARNING: multiple messages have this Message-ID (diff)
From: Eric Auger <eric.auger@linaro.org>
To: Alex Williamson <alex.williamson@redhat.com>, eric.auger@st.com
Cc: robin.murphy@arm.com, will.deacon@arm.com, joro@8bytes.org,
tglx@linutronix.de, jason@lakedaemon.net, marc.zyngier@arm.com,
christoffer.dall@linaro.org,
linux-arm-kernel@lists.infradead.org, patches@linaro.org,
linux-kernel@vger.kernel.org, Bharat.Bhushan@freescale.com,
pranav.sawargaonkar@gmail.com, p.fedin@samsung.com,
iommu@lists.linux-foundation.org, Jean-Philippe.Brucker@arm.com,
julien.grall@arm.com
Subject: Re: [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: 39+ 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 ` Eric Auger
2016-04-28 8:15 ` Eric Auger
[not found] ` <1461831323-5480-1-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
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 ` Eric Auger
2016-04-28 8:15 ` 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 ` Eric Auger
2016-04-28 8:15 ` Eric Auger
2016-04-28 8:15 ` [PATCH v8 3/8] iommu: introduce an msi cookie Eric Auger
2016-04-28 8:15 ` Eric Auger
2016-04-28 8:15 ` Eric Auger
2016-04-28 8:15 ` [PATCH v8 4/8] iommu/msi-iommu: initialization Eric Auger
2016-04-28 8:15 ` Eric Auger
2016-04-28 8:15 ` 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 ` Eric Auger
2016-04-28 8:15 ` Eric Auger
2016-04-28 8:15 ` [PATCH v8 6/8] iommu/msi-iommu: iommu_msi_domain Eric Auger
2016-04-28 8:15 ` Eric Auger
2016-04-28 8:15 ` Eric Auger
[not found] ` <1461831323-5480-7-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-04-28 22:27 ` Alex Williamson
2016-04-28 22:27 ` Alex Williamson
2016-04-28 22:27 ` Alex Williamson
[not found] ` <20160428162740.28db4b8d-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-05-02 15:48 ` Eric Auger [this message]
2016-05-02 15:48 ` Eric Auger
2016-05-02 15:48 ` Eric Auger
[not found] ` <572776BD.2080503-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-05-02 20:23 ` Alex Williamson
2016-05-02 20:23 ` Alex Williamson
2016-05-02 20:23 ` Alex Williamson
[not found] ` <20160502142328.2d97f7a4-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-05-03 12:27 ` Eric Auger
2016-05-03 12:27 ` Eric Auger
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 ` Eric Auger
2016-04-28 8:15 ` Eric Auger
2016-04-28 8:15 ` [PATCH v8 8/8] iommu/arm-smmu: get/put the msi cookie Eric Auger
2016-04-28 8:15 ` Eric Auger
2016-04-28 8:15 ` 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-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=eric.auger-qxv4g6HH51o@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
--cc=julien.grall-5wv7dgnIgG8@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.