Hi,
On 1/14/19 8:26 PM, Jonathan Cameron wrote:
On Thu, 10 Jan 2019 11:00:23 +0800
Lu Baolu wrote:
When multiple domains per device has been enabled by the
device driver, the device will tag the default PASID for
the domain to all DMA traffics out of the subset of this
device; and the IOMMU
Hi,
On 1/14/19 7:22 PM, Jonathan Cameron wrote:
On Thu, 10 Jan 2019 11:00:20 +0800
Lu Baolu wrote:
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the
On Mon, 14 Jan 2019 21:48:06 +0100
Auger Eric wrote:
> Hi Alex,
>
> On 1/12/19 12:58 AM, Alex Williamson wrote:
> > On Tue, 8 Jan 2019 11:26:30 +0100
> > Eric Auger wrote:
> >
> >> This patch adds a new 64kB region aiming to report nested mode
> >> translation faults.
> >>
> >> The region
On Fri, Jan 11, 2019 at 10:12:31AM +0100, Joerg Roedel wrote:
> On Thu, Jan 10, 2019 at 12:02:05PM -0500, Konrad Rzeszutek Wilk wrote:
> > Why not use swiotlb_nr_tbl ? That is how drivers/gpu/drm use to figure if
> > they
> > need to limit the size of pages.
>
> That function just exports the
On Mon, Jan 14, 2019 at 09:19:35PM +0100, Christoph Hellwig wrote:
> > Christoph is saying that !IOMMU_PLATFORM devices should hide the
> > compatibility code in a special per-device DMA API implementation.
> > Which would be fine especially if we can manage not to introduce a bunch
> > of
Hi Alex,
On 1/12/19 12:58 AM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:30 +0100
> Eric Auger wrote:
>
>> This patch adds a new 64kB region aiming to report nested mode
>> translation faults.
>>
>> The region contains a header with the size of the queue,
>> the producer and consumer
On Mon, Jan 14, 2019 at 09:14:08PM +0100, Christoph Hellwig wrote:
> Otherwise is_swiotlb_buffer will return false positives when
> we first initialize a swiotlb buffer, but then free it because
> we have an IOMMU available.
>
> Fixes: 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the
On Mon, Jan 14, 2019 at 07:12:08PM +, Robin Murphy wrote:
> On 14/01/2019 18:20, Michael S. Tsirkin wrote:
> > On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
> > >
> > > On 2019/1/14 下午5:50, Christoph Hellwig wrote:
> > > > On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang
On Mon, Jan 14, 2019 at 03:25:13PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 14, 2019 at 09:14:08PM +0100, Christoph Hellwig wrote:
> > Otherwise is_swiotlb_buffer will return false positives when
> > we first initialize a swiotlb buffer, but then free it because
> > we have an IOMMU
Hello everyone,
first of all thanks to Marek for looking into this.
@Robin: This works for me. The drivers now probe and bind correctly again.
With best wishes,
Tobias
Robin Murphy wrote:
> On 14/01/2019 16:09, Thierry Reding wrote:
>> On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski
On Mon, Jan 14, 2019 at 07:12:08PM +, Robin Murphy wrote:
> Now, in theory, yes, the real issue at hand is not unique to virtio-blk nor
> SEV - any driver whose device has a sufficiently large DMA segment size and
> who manages to get sufficient physically-contiguous memory could
>
On Mon, Jan 14, 2019 at 01:20:45PM -0500, Michael S. Tsirkin wrote:
> I don't think so - the issue is really that DMA API does not yet handle
> the SEV case 100% correctly. I suspect passthrough devices would have
> the same issue.
The DMA API handles the SEV case perfectly. Its just that
On 1/14/19 12:20 PM, Michael S. Tsirkin wrote:
> On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
>>
>> On 2019/1/14 下午5:50, Christoph Hellwig wrote:
>>> On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
On 2019/1/11 下午5:15, Joerg Roedel wrote:
> On Fri, Jan 11,
On Mon, 14 Jan 2019 at 19:10, Christoph Hellwig wrote:
>
> On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote:
> > On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote:
> > >
> > > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> > > >> From the trace it looks like
On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
>
> On 2019/1/14 下午5:50, Christoph Hellwig wrote:
> > On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
> > > On 2019/1/11 下午5:15, Joerg Roedel wrote:
> > > > On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
> > > >
Hmm, I wonder if we are not actually using swiotlb in the end,
can you check if your dmesg contains this line or not?
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
If not I guess we found a bug in swiotlb exit vs is_swiotlb_buffer,
and you can try this patch:
diff --git
On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote:
> >
> > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> > >> From the trace it looks like we git the case where swiotlb tries
> > >> to copy back data from a
On 2019-01-10 3:48 p.m., Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
>>> From the trace it looks like we git the case where swiotlb tries
>>> to copy back data from a bounce buffer, but hits a dangling or NULL
>>> pointer. So a couple questions for
On Mon, Jan 14, 2019 at 01:12:33PM +, Robin Murphy wrote:
> Ignoring the offset was kind of intentional there, because at the time I
> was primarily thinking about it in terms of the Keystone 2 platform where
> the peripherals are all in the same place (0-2GB) in both the bus and CPU
>
On Mon, Jan 14, 2019 at 04:52:40PM +, Robin Murphy wrote:
> One general point for the kmap() conversions - it's not obvious (to me at
> least) whether or how that would work for a segment where sg->length >
> PAGE_SIZE. Or is there some cast-iron guarantee from the MMC mid-layer that
> it
On 14/01/2019 09:57, Christoph Hellwig wrote:
Hi everyone,
this series converts the remaining MMC host drivers to properly kmap the
scatterlist entries it does PIO operations on, and then goes on to
remove the usage of block layer bounce buffering (which I plan to remove
eventually) from the
On 14/01/2019 16:09, Thierry Reding wrote:
On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski wrote:
This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
That patch broke IOMMU support for devices, which fails to probe for the
first time and use deferred probe approach. When
On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski wrote:
> This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
>
> That patch broke IOMMU support for devices, which fails to probe for the
> first time and use deferred probe approach. When non-NULL dma_ops is set
> in
Hi Robin,
On 1/14/19 12:10 PM, Robin Murphy wrote:
> On 10/01/2019 10:44, Auger Eric wrote:
>> Hi Robin, Drew,
>>
>> On 12/19/18 2:18 PM, Andrew Jones wrote:
>>> On Wed, Dec 19, 2018 at 12:21:35PM +, Robin Murphy wrote:
On 18/12/2018 18:48, Andrew Jones wrote:
> The sum of dmaaddr
On 11/01/2019 18:17, Christoph Hellwig wrote:
Use WARN_ON_ONCE to print a stack trace and return a proper error
code instead.
I was racking my brain to remember the reasoning behind BUG_ON() being
the only viable way to prevent errors getting through unhandled, but of
course that was before
This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
That patch broke IOMMU support for devices, which fails to probe for the
first time and use deferred probe approach. When non-NULL dma_ops is set
in arm_iommu_detach_device(), the given device later ignored by
arch_setup_dma_ops() and
On 11/01/2019 18:17, Christoph Hellwig wrote:
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation
Hi Christoph,
On 2019-01-11 19:17, Christoph Hellwig wrote:
> Hi all,
>
> this series fixes a rather gross layering violation in videobuf2, which
> pokes into arm DMA mapping internals to get a DMA address for memory that
> does not have a page structure, and to do so fixes up the
On Thu, 10 Jan 2019 11:00:22 +0800
Lu Baolu wrote:
> This part of code could be used by both normal and aux
> domain specific attach entries. Hence move them into a
> common function to avoid duplication.
>
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Kevin Tian
> Signed-off-by: Lu Baolu
Another
On Thu, 10 Jan 2019 11:00:20 +0800
Lu Baolu wrote:
> Sharing a physical PCI device in a finer-granularity way
> is becoming a consensus in the industry. IOMMU vendors
> are also engaging efforts to support such sharing as well
> as possible. Among the efforts, the capability of support
>
On 10/01/2019 10:44, Auger Eric wrote:
Hi Robin, Drew,
On 12/19/18 2:18 PM, Andrew Jones wrote:
On Wed, Dec 19, 2018 at 12:21:35PM +, Robin Murphy wrote:
On 18/12/2018 18:48, Andrew Jones wrote:
The sum of dmaaddr and size may overflow, particularly considering
there are cases where size
Em Mon, 14 Jan 2019 11:31:39 +0100
Christoph Hellwig escreveu:
> On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 11 Jan 2019 19:17:31 +0100
> > Christoph Hellwig escreveu:
> >
> > > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > >
+Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig wrote:
>
> Hi everyone,
>
> this series converts the remaining MMC host drivers to properly kmap the
> scatterlist entries it does PIO operations on, and then goes on to
>
On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 11 Jan 2019 19:17:31 +0100
> Christoph Hellwig escreveu:
>
> > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > resemblance of a dma address for a a physical address that does is
> > not
All MMC and SD host drivers are highmem safe now, and bounce buffering
for addressing limitations is handled in the DMA layer now.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/core/queue.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/mmc/core/queue.c
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/s3cmci.c | 107 +++---
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do a kmap for the page while
doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/moxart-mmc.c | 19 +++
1 file changed, 11
These days the DMA mapping code must bounce buffer for any not supported
address, and if they driver needs to optimize for natively supported
ranged it should use dma_get_required_mask.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 7 ---
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/sh_mmcif.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/mvsdio.c | 48 +++
1
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/omap.c | 15 ++-
1 file changed, 10
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/sh_mmcif.c | 58 +++--
1
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/s3cmci.c | 19 +--
drivers/mmc/host/s3cmci.h | 2 +-
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/omap.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap.c
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/davinci_mmc.c | 43 --
1
Hi everyone,
this series converts the remaining MMC host drivers to properly kmap the
scatterlist entries it does PIO operations on, and then goes on to
remove the usage of block layer bounce buffering (which I plan to remove
eventually) from the MMC layer.
As a bonus I've converted various
On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
>
> On 2019/1/11 下午5:15, Joerg Roedel wrote:
>> On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
>>> Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
>>> all virtio devices under AMD-SEV guests?
>> Yes,
With most of the previous functionality now elsewhere a lot of the
headers included in this file are not needed.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 13 +
include/linux/dma-iommu.h | 13 +
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index e27909771d55..1b76121df94e 100644
---
For entirely dma coherent architectures there is no good reason to ever
remap dma coherent allocation. Move all the remap and pool code under
CONFIG_DMA_DIRECT_REMAP ifdefs, and drop the Kconfig dependency.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/Kconfig | 1 -
There is no need to remap for pte attributes, or for a virtually
contiguous address, so just don't do it.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c
Moving this function up to its unmap counterpart helps to keep related
code together for the following changes.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 46 +++
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git
The current iommu_dma_mmap code does not properly handle memory from the
page allocator that hasn't been remapped, which can happen in the rare
case of allocations for a coherent device that aren't allowed to block.
Fix this by replacing iommu_dma_mmap with a slightly tweaked copy of
This moves the last remaning non-dispatch code out of iommu_dma_alloc,
preparing to refactor the allocation method selection.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 48 +++
1 file changed, 29 insertions(+), 19 deletions(-)
diff
This keeps the code together and will simplify compiling the code
out on architectures that are always dma coherent.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 51 +--
1 file changed, 38 insertions(+), 13 deletions(-)
diff --git
Reorder the checks a bit so that a non-remapped allocation is the
fallthrough case, as this will ease making remapping conditional.
Also get rid of the confusing game with the size and iosize variables
and rename the handle argument to the more standard dma_handle.
Signed-off-by: Christoph
This keeps the code together and will simplify using it in different
ways.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 110 --
1 file changed, 59 insertions(+), 51 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c
The current iommu_dma_get_sgtable code does not properly handle memory
from the page allocator that hasn't been remapped, which can happen in
the rare case of allocations for a coherent device that aren't allowed
to block.
Fix this by replacing iommu_dma_get_sgtable with a slightly tweaked copy
Directly iterating over the pages makes the code a bit simpler and
prepares for the following changes.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 40 +--
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git
There is nothing really arm64 specific in the iommu_dma_ops
implementation, so move it to dma-iommu.c and keep a lot of symbols
self-contained. Note the implementation does depend on the
DMA_DIRECT_REMAP infrastructure for now, so we'll have to make the
DMA_IOMMU support depend on it, but this
Hi Robin,
please take a look at this series, which implements a completely generic
set of dma_map_ops for IOMMU drivers. This is done by taking the
existing arm64 code, moving it to drivers/iommu and then massaging it
so that it can also work for architectures with DMA remapping. This
should
On 2019/1/11 下午5:15, Joerg Roedel wrote:
On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
all virtio devices under AMD-SEV guests?
Yes, that is correct. Emulated DMA can only happen on the SWIOTLB
aperture,
No need for a __KERNEL__ guard outside uapi, make sure we pull in the
includes unconditionally so users can rely on it, and add a missing
comment describing the #else cpp statement. Last but not least include
instead of the asm version, which is frowned upon.
Signed-off-by: Christoph Hellwig
63 matches
Mail list logo
