On 28-09-2017 03:43, Casey Leedom wrote:
> | From: Raj, Ashok
> | Sent: Wednesday, September 27, 2017 12:07 PM
> |
> | looking at the debug output i got from Harsh it still looks like a bug in
> | the code.
> |
> | [ 538.284589] __domain_mapping nr_pages 0x1
> | [ 538.284600] __domain_mapping sg
| From: Raj, Ashok
| Sent: Wednesday, September 27, 2017 12:07 PM
|
| looking at the debug output i got from Harsh it still looks like a bug in
| the code.
|
| [ 538.284589] __domain_mapping nr_pages 0x1
| [ 538.284600] __domain_mapping sg_res 0x1 sg->dma_address 0xf291000e dma len
| 0x38 pteval
Hi Casey
looking at the debug output i got from Harsh it still looks like
a bug in the code.
[ 538.284589] __domain_mapping nr_pages 0x1
[ 538.284600] __domain_mapping sg_res 0x1 sg->dma_address 0xf291000e dma len
0x38 pteval 0x3cbce3003 phys_pfn 0x3cbce3
[ 538.284604] chelsio driver - offse
Hey Raj,
Let us know if you need help in gathering more debugging information. For
the time being we've decided to ERRATA the use of the Intel I/O MMU with
IPsec till we Root Cause the issue. But this is still at the top of Harsh's
bug list.
With Robin's comments, I'm almost sure that the:
On Wed, 27 Sep 2017 15:40:41 +0200
Joerg Roedel wrote:
> Hi,
>
> On Wed, Sep 20, 2017 at 01:09:47PM +0100, Jean-Philippe Brucker wrote:
> > For binding page tables instead of PASID tables (e.g.
> > virtio-iommu), the generic data would be:
> >
> > struct pgtable_info {
> > __u32 pasid;
>
Hi Robin
On Wed, Sep 27, 2017 at 06:18:02PM +0100, Robin Murphy wrote:
> On Wed, 27 Sep 2017 16:31:04 +
> Casey Leedom wrote:
>
> > | From: Dan Williams
> > | Sent: Tuesday, September 26, 2017 9:10 AM
> > |
> > | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom
> > wrote: | > | From: Robin
| From: Robin Murphy
| Sent: Wednesday, September 27, 2017 10:18 AM
|
| From my experience, in general terms each scatterlist segment
| represents some contiguous quantity of pages, of which sg->page is the
| first, while sg->length and sg->offset describe the specific bounds of
| that segment's
On Wed, 27 Sep 2017 16:31:04 +
Casey Leedom wrote:
> | From: Dan Williams
> | Sent: Tuesday, September 26, 2017 9:10 AM
> |
> | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom
> wrote: | > | From: Robin Murphy
> | > | Sent: Tuesday, September 26, 2017 7:22 AM
> | > |...
> | > ...
> | >
On Wed, Sep 27, 2017 at 9:31 AM, Casey Leedom wrote:
> | From: Dan Williams
> | Sent: Tuesday, September 26, 2017 9:10 AM
> |
> | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom wrote:
> | > | From: Robin Murphy
> | > | Sent: Tuesday, September 26, 2017 7:22 AM
> | > |...
> | > ...
> | > Regard
On Wed, 27 Sep 2017 16:00:51 +0200
Joerg Roedel wrote:
> On Tue, Sep 19, 2017 at 02:48:41PM +0100, Robin Murphy wrote:
> > When devices with different DMA masks are using the same domain, or
> > for PCI devices where we usually try a speculative 32-bit
> > allocation first, there is a fair possib
| From: Dan Williams
| Sent: Tuesday, September 26, 2017 9:10 AM
|
| On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom wrote:
| > | From: Robin Murphy
| > | Sent: Tuesday, September 26, 2017 7:22 AM
| > |...
| > ...
| > Regardless, it seems that you agree that there's an issue with the Intel
|
On Wed, Sep 27, 2017 at 9:49 AM, Jean-Philippe Brucker
wrote:
> Hi Joerg,
>
> On 27/09/17 13:15, Joerg Roedel wrote:
>> Hi Rob, Jean,
>>
>> On Fri, Sep 22, 2017 at 02:42:44PM -0400, Rob Clark wrote:
>>> I'm in favour if splitting the reporting *somehow*.. the two
>>> approaches that seemed sane ar
I see now that this is redundant with Robin's patch series "Optimise
64-bit IOVA allocations". I tested those patches on our platform and
find that they solve the performance problem we were having. So, I'd
like to withdraw this patch.
On 9/27/2017 10:10 AM, Joerg Roedel wrote:
Adding Robi
On Thu, Sep 21, 2017 at 04:52:41PM +0100, Robin Murphy wrote:
> v4: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1493704.html
>
> Right, this is hopefully the last version - I've put things back in a
> sensible order with the new additions at the end, so if they prove
> contentious
On Tue, Sep 26, 2017 at 07:32:52PM +0100, Jean-Philippe Brucker wrote:
> The definition of map_sg was split during a recent addition to iommu_ops.
> Put it back together.
>
> Fixes: add02cfdc9bc ("iommu: Introduce Interface for IOMMU TLB Flushing")
> Signed-off-by: Jean-Philippe Brucker
> ---
>
On Tue, Sep 26, 2017 at 01:07:46PM +0530, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated. So replace '/n' with '\n'.
>
> Signed-off-by: Arvind Yadav
> ---
> drivers/iommu/amd_iommu_init.c | 8
> 1 file changed, 4 insertion
On Mon, Sep 25, 2017 at 06:15:26PM +0800, Yong Wu wrote:
> Signed-off-by: Yong Wu
> ---
> Base on v4.14-rc1.
Applied to iommu/fixes, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iomm
On Mon, Sep 25, 2017 at 05:28:47PM +0800, Yong Wu wrote:
> Fix the commit 81b3c2521844 ("iommu/io-pgtable: Introduce explicit
> coherency"). If there is no IO_PGTABLE_QUIRK_NO_DMA, we should call
> dma_sync_single_for_device for cache synchronization.
>
> Signed-off-by: Yong Wu
Applied to iommu/
Hi Jean,
On Wed, Sep 27, 2017 at 02:49:00PM +0100, Jean-Philippe Brucker wrote:
> I like this approach. When the device driver registers a fault handler,
> it also tells when it would like to be called (either in atomic context,
> blocking context, or both).
Is there a use-case for calling the sa
On 2017-09-27 15:21, Jan Kiszka wrote:
> On 2017-09-27 14:14, Jan Kiszka wrote:
>> Hi,
>>
>> while I'm triggering this with a still out-of-tree module from the
>> Jailhouse project, the potential deadlock appears to me being unrelated
>> to it. Please have a look:
>>
>>
Adding Robin.
Robin, can you please have a look?
On Wed, Sep 20, 2017 at 11:28:19AM -0400, David Woods wrote:
> When allocating pages with alloc_iova() where limit_pfn > dma_32bit_pfn
> __alloc_and_insert_iova_range does a linear traversal of the tree to
> find a free block. In the worst case it
On Tue, Sep 19, 2017 at 02:48:41PM +0100, Robin Murphy wrote:
> When devices with different DMA masks are using the same domain, or for
> PCI devices where we usually try a speculative 32-bit allocation first,
> there is a fair possibility that the top PFN of the rcache stack at any
> given time ma
Hi Joerg,
On 27/09/17 13:15, Joerg Roedel wrote:
> Hi Rob, Jean,
>
> On Fri, Sep 22, 2017 at 02:42:44PM -0400, Rob Clark wrote:
>> I'm in favour if splitting the reporting *somehow*.. the two
>> approaches that seemed sane are:
>>
>> 1) call fault handler from irq and having separate domain->res
Hi,
On Wed, Sep 20, 2017 at 01:09:47PM +0100, Jean-Philippe Brucker wrote:
> For binding page tables instead of PASID tables (e.g. virtio-iommu), the
> generic data would be:
>
> struct pgtable_info {
> __u32 pasid;
> __u64 ptr;
> __u32 model;
> __u8model_data[];
From: John Garry
On some platforms msi-controller address regions have to be excluded
from normal IOVA allocation in that they are detected and decoded in
a HW specific way by system components and so they cannot be considered
normal IOVA address space.
Add a helper function that retrieves msi a
The HiSilicon erratum 161010801 describes the limitation of HiSilicon
platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCI
IOMMU drivers can use this to implement their .get_resv_regions callback
for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
Signed-off-by: Shameer Kolothum
[John: added DT support]
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 19 +++
include/linux/dma-
On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.
The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI
From: John Garry
The HiSilicon erratum 161010801 describes the limitation of HiSilicon
platforms hip06/hip07 to support the SMMU mappings for MSI transactions.
On these platforms, GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the devi
On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.
Add a helper function that retrieves ITS address regions - the ms
On 2017-09-27 14:14, Jan Kiszka wrote:
> Hi,
>
> while I'm triggering this with a still out-of-tree module from the
> Jailhouse project, the potential deadlock appears to me being unrelated
> to it. Please have a look:
>
> ==
> WARNING: possible
On 27/09/17 13:27, Joerg Roedel wrote:
> Hi Will, Robin,
>
> On Fri, Sep 22, 2017 at 04:43:22PM +0100, Will Deacon wrote:
>> Joerg, do you reckon it's worth merging this as-is, or should we also
>> hook up add_flush before implementing this?
>
> The patches implement .iotlb_sync() so that it is o
Hi Will, Robin,
On Fri, Sep 22, 2017 at 04:43:22PM +0100, Will Deacon wrote:
> Joerg, do you reckon it's worth merging this as-is, or should we also
> hook up add_flush before implementing this?
The patches implement .iotlb_sync() so that it is okay to not have a
.iotlb_range_add() call-back for
Hi Rob, Jean,
On Fri, Sep 22, 2017 at 02:42:44PM -0400, Rob Clark wrote:
> I'm in favour if splitting the reporting *somehow*.. the two
> approaches that seemed sane are:
>
> 1) call fault handler from irq and having separate domain->resume()
> called by the driver, potentially from a wq
> 2) or
Hi,
while I'm triggering this with a still out-of-tree module from the
Jailhouse project, the potential deadlock appears to me being unrelated
to it. Please have a look:
==
WARNING: possible circular locking dependency detected
4.14.0-rc2-dbg+ #
[+DMA maintainers]
On 27/09/17 04:48, miles.c...@mediatek.com wrote:
> From: Miles Chen
>
> dma-debug reports the following warning:
>
> [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604
> debug _dma_assert_idle+0x1a8/0x230()
> DMA-API: cpu touching an active dma mapped ca
36 matches
Mail list logo
