out_unmap:
pr_err("%s: IOMMU mapping error in map_sg (io-pages: %d)\n",
dev_name(dev), npages);
for_each_sg(sglist, s, nelems, i) {
int j, pages = iommu_num_pages(sg_phys(s), s->length,
PAGE_SIZE);
for (j = 0; j < pages;
On Thu, 17 Jan 2019, Christoph Hellwig wrote:
> Xen-swiotlb hooks into the arm/arm64 arch code through a copy of the
> DMA mapping operations stored in the struct device arch data.
>
> Switching arm64 to use the direct calls for the merged DMA direct /
> swiotlb code broke this scheme. Replace
On Thu, 17 Jan 2019, Christoph Hellwig wrote:
> On Thu, Jan 17, 2019 at 11:43:49AM +, Julien Grall wrote:
> > Looking at the change for arm64, you will always call dma-direct API. In
> > previous Linux version, xen-swiotlb will call dev->archdata.dev_dma_ops (a
> > copy of dev->dma_ops before
Currently the Intel IOMMU uses the default dma_[un]map_resource()
implementations does nothing and simply returns the physical address
unmodified.
However, this doesn't create the IOVA entries necessary for addresses
mapped this way to work when the IOMMU is enabled. Thus, when the
IOMMU is
Hi Laurentiu,
On Fri, Jan 18, 2019 at 12:06:23PM +0200, Laurentiu Tudor wrote:
> This mapping needs to be created in order for slave dma transfers
> to work on systems with SMMU. The implementation mostly mimics the
> one in pl330 dma driver, authored by Robin Murphy.
>
> Signed-off-by:
On Tue, Jan 15, 2019 at 12:19:52PM +, Jean-Philippe Brucker wrote:
> Implement the virtio-iommu driver, following specification v0.9 [1].
>
> This is a simple rebase onto Linux v5.0-rc2. We now use the
> dev_iommu_fwspec_get() helper introduced in v5.0 instead of accessing
>
On Fri, Jan 18, 2019 at 09:53:22AM +0530, Srinath Mannam wrote:
> In the current implementation, config read of 0x0001 data
> is assumed as CRS completion. but sometimes 0x0001 can be
> a valid data.
> IPROC PCIe RC has a register to show config request status flags
> like SC, UR, CRS and
On Fri, Jan 18, 2019 at 09:53:21AM +0530, Srinath Mannam wrote:
> Order mode in RX header of incoming pcie packets can be override to
> strict or loose order based on requirement.
> Sysfs entry is provided to set dynamic and default order modes of upstream
> traffic.
s/pcie/PCIe/
If this is two
Hello Christoph,
I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your
Git powerpc-dma.6-debug today.
Unfortunately I don't see any error messages (kernel ring buffer) and I
don't have a RS232 serial null modem cable to get them.
Cheers,
Christian
On Fri, Jan 18, 2019 at 09:53:20AM +0530, Srinath Mannam wrote:
> Add changes related to IPROC PCIe RC IP new features.
>
> This patch set is based on Linux-5.0-rc2.
>
> Srinath Mannam (3):
> PCI: iproc: Add feature to set order mode
Since this apparently refers to a PCIe feature, the subject
Hi Pierre,
On 18/01/2019 13:29, Pierre Morel wrote:
> On 17/01/2019 14:02, Robin Murphy wrote:
>> On 15/01/2019 17:37, Pierre Morel wrote:
>>> The s390 iommu can only allow DMA transactions between the zPCI device
>>> entries start_dma and end_dma.
>>>
>>> Let's declare the regions before
While debugging a DMA mapping leak, I needed to access
debug_dma_dump_mappings() but easily from user space.
This patch adds a /sys/kernel/debug/dma-api/dump file which contain all
current DMA mapping.
Signed-off-by: Corentin Labbe
---
Changes since v1:
- Use DEFINE_SHOW_ATTRIBUTE
- Add
On Wed, Jan 16, 2019 at 06:10:13PM +, Robin Murphy wrote:
> On 16/01/2019 13:44, Corentin Labbe wrote:
> > While debugging a DMA mapping leak, I needed to access
> > debug_dma_dump_mappings() but easily from user space.
> >
> > This patch adds a /sys/kernel/debug/dma-api/dump file which
On 17/01/2019 14:02, Robin Murphy wrote:
On 15/01/2019 17:37, Pierre Morel wrote:
The s390 iommu can only allow DMA transactions between the zPCI device
entries start_dma and end_dma.
Let's declare the regions before start_dma and after end_dma as
reserved regions using the appropriate
On Fri, Jan 18, 2019 at 01:46:46PM +0100, Christian Zigotzky wrote:
> Sorry, it's not possible to patch
> '257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried it
> manually but without any success.
Weird:
hch@carbon:~/work/linux$ git checkout
Sorry, it's not possible to patch
'257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried
it manually but without any success.
-- Christian
On 18 January 2019 at 1:18PM, Christoph Hellwig wrote:
On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
git clone
On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 257002094bc5935dd63207a380d9698ab81f0775
>
>
> I get the following error message with your patch:
Hmm. Did I attached the wrong patch?
Joonas Lahtinen wrote:
> Quoting Eric Wong (2019-01-04 03:06:26)
> > Yeah, so the Debian bpo 4.17(.17) kernel did not set
> > CONFIG_INTEL_IOMMU_DEFAULT_ON, so I didn't encounter problems.
> > My self-built kernels all set CONFIG_INTEL_IOMMU_DEFAULT_ON.
>
> So it's the case that IOMMU never
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 257002094bc5935dd63207a380d9698ab81f0775
I get the following error message with your patch:
patching file a/kernel/dma/direct.c
Hunk #1 FAILED at 118.
Hunk #2 FAILED at 139.
2 out of 2 hunks FAILED -- saving
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 backed by a page struct. Not only is this not portable to other
architectures with dma direct mapping offsets, but also not to uses
of IOMMUs of any kind.
Instead provide a proper implementation in the direct mapping code, and
also wire it up for arm and powerpc, leaving an error return for all the
IOMMU or virtual mapping instances for which we'd have to wire up an
actual implementation
Signed-off-by: Christoph Hellwig
---
Use WARN_ON_ONCE to print a stack trace and return a proper error
code instead.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
include/linux/dma-mapping.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h
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 dma_map_resource
implementation to not provide a somewhat dangerous default and
On Wed, Jan 16, 2019 at 06:10:13PM +, Robin Murphy wrote:
> It's a shame that this is pretty much a duplication of
> debug_dma_dump_mappings(), but there seems no straightforward way to define
> one in terms of the other :/
We could always play some macro magic, but I think that is worse
On Fri, Jan 18, 2019 at 12:10:26PM +0100, Christian Zigotzky wrote:
> For which commit?
On top of 257002094bc5935dd63207a380d9698ab81f0775, that is the first
one you identified as breaking the detection of the SATA disks.
___
iommu mailing list
For which commit?
-- Christian
On 18 January 2019 at 09:35AM, Christoph Hellwig wrote:
Hi Christian,
can you check if the debug printks in this patch trigger?
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++
This mapping needs to be created in order for slave dma transfers
to work on systems with SMMU. The implementation mostly mimics the
one in pl330 dma driver, authored by Robin Murphy.
Signed-off-by: Laurentiu Tudor
Suggested-by: Robin Murphy
---
Original approach was to add the missing mappings
Hi,
On 1/8/19 11:26 AM, Eric Auger wrote:
> This series allows a virtualizer to program the nested stage mode.
> This is useful when both the host and the guest are exposed with
> an SMMUv3 and a PCI device is assigned to the guest using VFIO.
>
> In this mode, the physical IOMMU must be
Hi Christoph,
On 2019-01-17 18:21, Christoph Hellwig wrote:
> On Mon, Jan 14, 2019 at 01:42:26PM +0100, Marek Szyprowski wrote:
>> On 2019-01-11 19:17, Christoph Hellwig wrote:
>>> vb2_dc_get_userptr pokes into arm direct mapping details to get the
>>> resemblance of a dma address for a a
Hi Christian,
can you check if the debug printks in this patch trigger?
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device
30 matches
Mail list logo
