From: Christoph Hellwig <hch@infradead.org>
To: Ajay Kumar <ajaykumar.rs@samsung.com>
Cc: mark.rutland@arm.com, robin.murphy@arm.com,
linux-kernel@vger.kernel.org, hch@infradead.org,
iommu@lists.linux-foundation.org, robh+dt@kernel.org,
will@kernel.org, nleeder@codeaurora.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC V2 PATCH] dma-iommu: allow devices to set IOVA range dynamically
Date: Tue, 11 Aug 2020 06:49:12 +0100 [thread overview]
Message-ID: <20200811054912.GA301@infradead.org> (raw)
In-Reply-To: <20200810175812.29100-1-ajaykumar.rs@samsung.com>
On Mon, Aug 10, 2020 at 11:28:12PM +0530, Ajay Kumar wrote:
> Currently, there is no other option to change the lower limit of
> IOVA for any device than calling iova_init_domain(), but the
> said function will re-init whole domain and also doesn't track
> the previously allocated IOVA before re-initing the domain.
>
> There are cases where the device might not support continuous
> range of addresses, and can also have dependency among buffers
> allocated for firmware, image manipulation, etc and all of the
> address requests pass through IOMMU. In such cases, we can allocate
> buffers stage by stage by setting address limit, and also keep
> track the of same.
>
> Bit of background can be found here:
> IOVA allocation dependency between firmware buffer and remaining buffers
> https://www.spinics.net/lists/iommu/msg43586.html
>
> This patch allows devices to limit the IOVA space they want
> during allocation at any given point of time. We shall allow
> the same only if the device owns the corresponding iommu_domain,
> that is the device is the only master attached to the domain.
>
> The lower limit of IOVA space is marked by start_pfn, and the upper
> limit is marked by dma_mask and this patch honors the same.
> Since changing dma_mask can extend the addressable region beyond
> current cached node, we do a reset of current cached nodes as well.
>
> User drivers can make call sequence like below:
> ============================================================
> When they want to limit IOVA for allocated buffers in range
> 0x0 to 0x1000000:
> iommu_set_iova_range(dev, 0x0, 0x1000000 - 1);
>
> When they want to limit IOVA for allocated buffers in range
> 0x1000000 to 0xC0000000:
> iommu_set_iova_range(dev, 0x1000000, 0xC0000000 - 0x1000000);
> =============================================================
This still seems to be missing an actual user of the functionality.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Ajay Kumar <ajaykumar.rs@samsung.com>
Cc: mark.rutland@arm.com, robin.murphy@arm.com, joro@8bytes.org,
linux-kernel@vger.kernel.org, hch@infradead.org,
iommu@lists.linux-foundation.org, robh+dt@kernel.org,
will@kernel.org, nleeder@codeaurora.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC V2 PATCH] dma-iommu: allow devices to set IOVA range dynamically
Date: Tue, 11 Aug 2020 06:49:12 +0100 [thread overview]
Message-ID: <20200811054912.GA301@infradead.org> (raw)
In-Reply-To: <20200810175812.29100-1-ajaykumar.rs@samsung.com>
On Mon, Aug 10, 2020 at 11:28:12PM +0530, Ajay Kumar wrote:
> Currently, there is no other option to change the lower limit of
> IOVA for any device than calling iova_init_domain(), but the
> said function will re-init whole domain and also doesn't track
> the previously allocated IOVA before re-initing the domain.
>
> There are cases where the device might not support continuous
> range of addresses, and can also have dependency among buffers
> allocated for firmware, image manipulation, etc and all of the
> address requests pass through IOMMU. In such cases, we can allocate
> buffers stage by stage by setting address limit, and also keep
> track the of same.
>
> Bit of background can be found here:
> IOVA allocation dependency between firmware buffer and remaining buffers
> https://www.spinics.net/lists/iommu/msg43586.html
>
> This patch allows devices to limit the IOVA space they want
> during allocation at any given point of time. We shall allow
> the same only if the device owns the corresponding iommu_domain,
> that is the device is the only master attached to the domain.
>
> The lower limit of IOVA space is marked by start_pfn, and the upper
> limit is marked by dma_mask and this patch honors the same.
> Since changing dma_mask can extend the addressable region beyond
> current cached node, we do a reset of current cached nodes as well.
>
> User drivers can make call sequence like below:
> ============================================================
> When they want to limit IOVA for allocated buffers in range
> 0x0 to 0x1000000:
> iommu_set_iova_range(dev, 0x0, 0x1000000 - 1);
>
> When they want to limit IOVA for allocated buffers in range
> 0x1000000 to 0xC0000000:
> iommu_set_iova_range(dev, 0x1000000, 0xC0000000 - 0x1000000);
> =============================================================
This still seems to be missing an actual user of the functionality.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Ajay Kumar <ajaykumar.rs@samsung.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org,
mark.rutland@arm.com, will@kernel.org, joro@8bytes.org,
nleeder@codeaurora.org, robin.murphy@arm.com, hch@infradead.org
Subject: Re: [RFC V2 PATCH] dma-iommu: allow devices to set IOVA range dynamically
Date: Tue, 11 Aug 2020 06:49:12 +0100 [thread overview]
Message-ID: <20200811054912.GA301@infradead.org> (raw)
In-Reply-To: <20200810175812.29100-1-ajaykumar.rs@samsung.com>
On Mon, Aug 10, 2020 at 11:28:12PM +0530, Ajay Kumar wrote:
> Currently, there is no other option to change the lower limit of
> IOVA for any device than calling iova_init_domain(), but the
> said function will re-init whole domain and also doesn't track
> the previously allocated IOVA before re-initing the domain.
>
> There are cases where the device might not support continuous
> range of addresses, and can also have dependency among buffers
> allocated for firmware, image manipulation, etc and all of the
> address requests pass through IOMMU. In such cases, we can allocate
> buffers stage by stage by setting address limit, and also keep
> track the of same.
>
> Bit of background can be found here:
> IOVA allocation dependency between firmware buffer and remaining buffers
> https://www.spinics.net/lists/iommu/msg43586.html
>
> This patch allows devices to limit the IOVA space they want
> during allocation at any given point of time. We shall allow
> the same only if the device owns the corresponding iommu_domain,
> that is the device is the only master attached to the domain.
>
> The lower limit of IOVA space is marked by start_pfn, and the upper
> limit is marked by dma_mask and this patch honors the same.
> Since changing dma_mask can extend the addressable region beyond
> current cached node, we do a reset of current cached nodes as well.
>
> User drivers can make call sequence like below:
> ============================================================
> When they want to limit IOVA for allocated buffers in range
> 0x0 to 0x1000000:
> iommu_set_iova_range(dev, 0x0, 0x1000000 - 1);
>
> When they want to limit IOVA for allocated buffers in range
> 0x1000000 to 0xC0000000:
> iommu_set_iova_range(dev, 0x1000000, 0xC0000000 - 0x1000000);
> =============================================================
This still seems to be missing an actual user of the functionality.
next prev parent reply other threads:[~2020-08-11 5:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200810182328epcas5p2d5ffb5a5850a641fe7d31aa945c6c835@epcas5p2.samsung.com>
2020-08-10 17:58 ` [RFC V2 PATCH] dma-iommu: allow devices to set IOVA range dynamically Ajay Kumar
2020-08-10 17:58 ` Ajay Kumar
2020-08-10 17:58 ` Ajay Kumar
2020-08-11 5:23 ` kernel test robot
2020-08-11 5:49 ` Christoph Hellwig [this message]
2020-08-11 5:49 ` Christoph Hellwig
2020-08-11 5:49 ` Christoph Hellwig
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=20200811054912.GA301@infradead.org \
--to=hch@infradead.org \
--cc=ajaykumar.rs@samsung.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=nleeder@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.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 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.