| Message ID | 1455264797-2334-8-git-send-email-eric.auger@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 12 Feb 2016 08:13:09 +0000 Eric Auger <eric.auger@linaro.org> wrote: > This patch introduces iommu_get/put_single_reserved. > > iommu_get_single_reserved allows to allocate a new reserved iova page > and map it onto the physical page that contains a given physical address. > It returns the iova that is mapped onto the provided physical address. > Hence the physical address passed in argument does not need to be aligned. > > In case a mapping already exists between both pages, the IOVA mapped > to the PA is directly returned. > > Each time an iova is successfully returned a binding ref count is > incremented. > > iommu_put_single_reserved decrements the ref count and when this latter > is null, the mapping is destroyed and the iova is released. I wonder if there is a requirement for the caller to find out about the size of the mapping, or to impose a given size... MSIs clearly do not have that requirement (this is always a 32bit value), but since allocations usually pair address and size, I though I'd ask... Thanks, M.
Hello, On 02/18/2016 12:06 PM, Marc Zyngier wrote: > On Fri, 12 Feb 2016 08:13:09 +0000 > Eric Auger <eric.auger@linaro.org> wrote: > >> This patch introduces iommu_get/put_single_reserved. >> >> iommu_get_single_reserved allows to allocate a new reserved iova page >> and map it onto the physical page that contains a given physical address. >> It returns the iova that is mapped onto the provided physical address. >> Hence the physical address passed in argument does not need to be aligned. >> >> In case a mapping already exists between both pages, the IOVA mapped >> to the PA is directly returned. >> >> Each time an iova is successfully returned a binding ref count is >> incremented. >> >> iommu_put_single_reserved decrements the ref count and when this latter >> is null, the mapping is destroyed and the iova is released. > > I wonder if there is a requirement for the caller to find out about the > size of the mapping, or to impose a given size... MSIs clearly do not > have that requirement (this is always a 32bit value), but since. > allocations usually pair address and size, I though I'd ask... Yes. Currently this only makes sure the host PA is mapped and returns the corresponding IOVA. It is part of the discussion we need to have on the API besides the problematic of which API it should belong to. Thanks Eric > > Thanks, > > M. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 18/02/16 16:42, Eric Auger wrote: > Hello, > On 02/18/2016 12:06 PM, Marc Zyngier wrote: >> On Fri, 12 Feb 2016 08:13:09 +0000 >> Eric Auger <eric.auger@linaro.org> wrote: >> >>> This patch introduces iommu_get/put_single_reserved. >>> >>> iommu_get_single_reserved allows to allocate a new reserved iova page >>> and map it onto the physical page that contains a given physical address. >>> It returns the iova that is mapped onto the provided physical address. >>> Hence the physical address passed in argument does not need to be aligned. >>> >>> In case a mapping already exists between both pages, the IOVA mapped >>> to the PA is directly returned. >>> >>> Each time an iova is successfully returned a binding ref count is >>> incremented. >>> >>> iommu_put_single_reserved decrements the ref count and when this latter >>> is null, the mapping is destroyed and the iova is released. >> >> I wonder if there is a requirement for the caller to find out about the >> size of the mapping, or to impose a given size... MSIs clearly do not >> have that requirement (this is always a 32bit value), but since. >> allocations usually pair address and size, I though I'd ask... > Yes. Currently this only makes sure the host PA is mapped and returns > the corresponding IOVA. It is part of the discussion we need to have on > the API besides the problematic of which API it should belong to. One of the issues I have with the API at the moment is that there is no control on the page size. Imagine you have allocated a 4kB IOVA window for your MSI, but your IOMMU can only map 64kB (not unreasonable to imagine on arm64). What happens then? Somehow, userspace should be told about it, one way or another. Thanks, M.
Hi Marc, On 02/18/2016 05:51 PM, Marc Zyngier wrote: > On 18/02/16 16:42, Eric Auger wrote: >> Hello, >> On 02/18/2016 12:06 PM, Marc Zyngier wrote: >>> On Fri, 12 Feb 2016 08:13:09 +0000 >>> Eric Auger <eric.auger@linaro.org> wrote: >>> >>>> This patch introduces iommu_get/put_single_reserved. >>>> >>>> iommu_get_single_reserved allows to allocate a new reserved iova page >>>> and map it onto the physical page that contains a given physical address. >>>> It returns the iova that is mapped onto the provided physical address. >>>> Hence the physical address passed in argument does not need to be aligned. >>>> >>>> In case a mapping already exists between both pages, the IOVA mapped >>>> to the PA is directly returned. >>>> >>>> Each time an iova is successfully returned a binding ref count is >>>> incremented. >>>> >>>> iommu_put_single_reserved decrements the ref count and when this latter >>>> is null, the mapping is destroyed and the iova is released. >>> >>> I wonder if there is a requirement for the caller to find out about the >>> size of the mapping, or to impose a given size... MSIs clearly do not >>> have that requirement (this is always a 32bit value), but since. >>> allocations usually pair address and size, I though I'd ask... >> Yes. Currently this only makes sure the host PA is mapped and returns >> the corresponding IOVA. It is part of the discussion we need to have on >> the API besides the problematic of which API it should belong to. > > One of the issues I have with the API at the moment is that there is no > control on the page size. Imagine you have allocated a 4kB IOVA window > for your MSI, but your IOMMU can only map 64kB (not unreasonable to > imagine on arm64). What happens then? The code checks the IOVA window size is aligned with the IOMMU page size so I think that case is handled at iova domain creation (arm_smmu_alloc_reserved_iova_domain). > > Somehow, userspace should be told about it, one way or another. I agree on that point. The user-space should be provided with the information about the requested iova pool size and alignments. This is missing in current rfc series. Best Regards Eric > > Thanks, > > M. > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index a994f34..14ebde1 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -1415,6 +1415,27 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size) return unmapped; } EXPORT_SYMBOL_GPL(iommu_unmap); +int iommu_get_single_reserved(struct iommu_domain *domain, + phys_addr_t addr, int prot, + dma_addr_t *iova) +{ + if (!domain->ops->get_single_reserved) + return -ENODEV; + + return domain->ops->get_single_reserved(domain, addr, prot, iova); + +} +EXPORT_SYMBOL_GPL(iommu_get_single_reserved); + +void iommu_put_single_reserved(struct iommu_domain *domain, + dma_addr_t iova) +{ + if (!domain->ops->put_single_reserved) + return; + + domain->ops->put_single_reserved(domain, iova); +} +EXPORT_SYMBOL_GPL(iommu_put_single_reserved); size_t default_iommu_map_sg(struct iommu_domain *domain, unsigned long iova, struct scatterlist *sg, unsigned int nents, int prot) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 2d1f155..1e00c1b 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -201,6 +201,21 @@ struct iommu_ops { unsigned long order); /* frees the reserved iova domain */ void (*free_reserved_iova_domain)(struct iommu_domain *domain); + /** + * allocate a reserved iova page and bind it onto the page that + * contains a physical address (@addr), returns the @iova bound to + * @addr. In case the 2 pages already are bound simply return @iova + * and increment a ref count. + */ + int (*get_single_reserved)(struct iommu_domain *domain, + phys_addr_t addr, int prot, + dma_addr_t *iova); + /** + * decrement a ref count of the iova page. If null, unmap the iova page + * and release the iova + */ + void (*put_single_reserved)(struct iommu_domain *domain, + dma_addr_t iova); #ifdef CONFIG_OF_IOMMU int (*of_xlate)(struct device *dev, struct of_phandle_args *args); @@ -276,6 +291,11 @@ extern int iommu_alloc_reserved_iova_domain(struct iommu_domain *domain, dma_addr_t iova, size_t size, unsigned long order); extern void iommu_free_reserved_iova_domain(struct iommu_domain *domain); +extern int iommu_get_single_reserved(struct iommu_domain *domain, + phys_addr_t paddr, int prot, + dma_addr_t *iova); +extern void iommu_put_single_reserved(struct iommu_domain *domain, + dma_addr_t iova); struct device *iommu_device_create(struct device *parent, void *drvdata, const struct attribute_group **groups, const char *fmt, ...) __printf(4, 5);