Hi Christoph,
a question arouse, is there a real value to dealing with PFNs (as opposed to
real addresses) in the core DMA code/structures? I see that in some cases it
eases interacting with mm, but the overwhelming usage of say,
dev->dma_pfn_offset, involves shifting it.
Hi Jim,
On Thu,
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of single or multiple pfn offsets between cpu addrs and dma addrs.
It subsumes the role of dev->dma_pfn_offset -- a uniform offset.
The function of_dma_get_range() has been modified to take two additional
arguments:
v4:
Commit "device core: Introduce multiple dma pfn offsets"
-- of_dma_get_range() does not take a dev param but instead
takes two "out" params: map and map_size. We do this so
that the code that parses dma-ranges is separate from
the code that modifies 'dev'. (Nicolas)
The IVRS ACPI table specifies maximum address sizes for I/O virtual
addresses that can be handled by the IOMMUs in the system. Parse that
data from the IVRS header so that it can be considered in limiting the
I/O aperture.
Based on prior work by Marius Hillenbrand.
Link:
The IVRS ACPI table specifies maximum address sizes for I/O virtual
addresses that can be handled by the IOMMUs in the system. Parse that
data from the IVRS header to provide aperture information for DMA
mappings and users of the iommu API.
Sebastian Ott (3):
iommu/amd: Parse supported address
Add a check to enforce that I/O virtual addresses picked by iommu API
users stay within the domains geometry aperture.
Signed-off-by: Sebastian Ott
---
drivers/iommu/amd_iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index
The IVRS ACPI table specifies maximum address sizes for I/O virtual
addresses. When allocating new protection domains that perform
translation, propagate these limits as the domain's geometry / aperture.
Based on prior work by Marius Hillenbrand.
Signed-off-by: Sebastian Ott
---
On Fri, Jun 5, 2020 at 1:27 PM Nicolas Saenz Julienne
wrote:
>
> Hi Christoph,
> a question arouse, is there a real value to dealing with PFNs (as opposed to
> real addresses) in the core DMA code/structures? I see that in some cases it
> eases interacting with mm, but the overwhelming usage of
On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote:
> On 2020/6/2 上午1:41, Bjorn Helgaas wrote:
> > On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:
> > > On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:
> > > > Is this slowdown significant? We already iterate
On Fri, Jun 05, 2020 at 11:57:51AM +0300, Dan Carpenter wrote:
> On Fri, Jun 05, 2020 at 06:04:31AM +, Song Bao Hua (Barry Song) wrote:
> >
> >
> > > -Original Message-
> > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > > Sent: Thursday, June 4, 2020 11:37 PM
> > > To:
When include/uapi/linux/iommu.h was created it was never
added to the file list in MAINTAINERS.
Cc: Joerg Roedel
Signed-off-by: Jerry Snitselaar
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e1897ed32930..061648b6e393 100644
---
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, June 4, 2020 11:37 PM
> To: kbu...@lists.01.org; Song Bao Hua (Barry Song)
> ; h...@lst.de; m.szyprow...@samsung.com;
> robin.mur...@arm.com; catalin.mari...@arm.com
> Cc: l...@intel.com; Dan
On Fri, Jun 05, 2020 at 06:04:31AM +, Song Bao Hua (Barry Song) wrote:
>
>
> > -Original Message-
> > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > Sent: Thursday, June 4, 2020 11:37 PM
> > To: kbu...@lists.01.org; Song Bao Hua (Barry Song)
> > ; h...@lst.de;
On 04.06.20 17:27, David Hildenbrand wrote:
> On 04.06.20 17:06, Christoph Hellwig wrote:
>> On Thu, Jun 04, 2020 at 01:32:40PM +0200, David Hildenbrand wrote:
>>> Just a thought: If memory hotplug is applicable as well, you might
>>> either want to always assume data->enable_4GB, or handle memory
Hi Barry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on linus/master v5.7]
[cannot apply to next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we
15 matches
Mail list logo
