All of lore.kernel.org
 help / color / mirror / Atom feed
From: Federico Vaga <federico.vaga-VIMSii5OdOuonA0d6jMUrA@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: IOMMU - DMA debugging
Date: Thu, 13 Jul 2017 10:43:27 +0200	[thread overview]
Message-ID: <22729074.Vd8Fat30YZ@harkonnen> (raw)
In-Reply-To: <9273b2ab-2648-63f7-fe0f-a4462b4e4062-5wv7dgnIgG8@public.gmane.org>

On Wednesday, July 12, 2017 8:02:42 PM CEST Robin Murphy wrote:
> On 12/07/17 18:20, Federico Vaga wrote:
> > On Wednesday, July 12, 2017 2:15:34 PM CEST Federico Vaga wrote:
> >> Thank you Robin
> >> 
> >> (inline comments)
> >> 
> >> On Wednesday, July 12, 2017 1:10:51 PM CEST Robin Murphy wrote:
> >>> On 12/07/17 08:11, Federico Vaga wrote:
> >>>> Hello,
> >>>> 
> >>>> kernel version 4.4.x
> >>>> 
> >>>> I'm facing an issue with the INTEL IOMMU driver and DMA mapping. I have
> >>>> an
> >>>> Ethernet driver that uses `dma_alloc_coherent()` to allocate and map
> >>>> some
> >>>> memory for DMA transfers.
> >>> 
> >>> Assuming 02:00.0 is your actual endpoint and not some upstream aliasing
> >>> bridge, is your driver definitely using the correct struct device
> >>> pointer corresponding to that for its DMA API calls?
> > 
> > I had a look at this point. The driver is using the device 02:08.0 (which
> > is the one that should use) but the errors refers to the 02:00.0. I have
> > a rough idea about how the IOMMU works but I do not know the details
> > involved in the process.
> > 
> > \-[0000:00]-+-00.0
> > 
> >              +-01.0-[01-02]----00.0-[02]----08.0      <<<<<<<<<<
> >              +-01.1-[03]----00.0
> 
> OK, this is what I suspected might be happening, thanks for confirming.
> 
> > Then among all the other devices, I have this from `dmesg`
> > 
> > [...]
> > [    2.212107] DMAR: Hardware identity mapping for device 0000:00:1f.3
> > [    2.219113] DMAR: Hardware identity mapping for device 0000:03:00.0
> > [    2.226118] DMAR: Hardware identity mapping for device 0000:04:00.0
> > [    2.233123] DMAR: Hardware identity mapping for device 0000:04:00.1
> > [...]
> > [    2.693295] iommu: Adding device 0000:00:1f.3 to group 22
> > [    2.699350] iommu: Adding device 0000:01:00.0 to group 23
> > [    2.705389] iommu: Adding device 0000:02:08.0 to group 23
> > [    2.711444] iommu: Adding device 0000:03:00.0 to group 24
> > [    2.717552] iommu: Adding device 0000:04:00.0 to group 25
> > [...]
> > 
> > 
> > It misses the message "Hardware identity mapping for device 0000:02:08.0".
> > Is it possible that there is not a valid DMAR table?
> 
> I'm a bit sketchy on intel-iommu details as well, but based on a quick
> scan through the code I'd assume your endpoint doesn't get an identity
> mapping because it's a PCI device behind a PCIe-to-PCI bridge (which
> ties in with the RID alias to DevFn 00.0). AFAICS that then means that
> the DMA ops should always give back a remapped address (i.e. iommu=pt
> ends up behaving the same as iommu=on), at which point it does start to
> look like your device is simply making bogus accesses.
> 
> The IOVA allocator will allocate DMA addresses downwards from
> 0xfffff000, but your reported fault addresses don't look anything like
> that, so I'd imagine that either some part of the driver is bypassing
> the DMA API and erroneously passing physical addresses to the hardware,

I don't think that this is the case. The addresses returned by 
dma_alloc_coherent are consistent with the IOVA logic:

[...]
[67594.620282] DMA addr 0x00000000ffffd000
[67594.620294] DMA addr 0x00000000ffffc000
[67594.620305] DMA addr 0x00000000ffffb000
[67594.620314] DMA addr 0x00000000ffffa000
[...]

and this is the address that is going to be programmed in the hardware 
register.


> or alternatively the hardware itself is going wrong somehow (e.g. trying
> to read a buffer address from an in-memory descriptor, getting back
> junk, and going downhill from there).

Probably it worth to have a look there
 
> Hope that helps,

Thank you

-- 
Federico Vaga
http://www.federicovaga.it/

  parent reply	other threads:[~2017-07-13  8:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-12  7:11 IOMMU - DMA debugging Federico Vaga
2017-07-12 11:10 ` Robin Murphy
     [not found]   ` <1c0e4473-9b50-fe0c-d544-71464360ab7f-5wv7dgnIgG8@public.gmane.org>
2017-07-12 12:15     ` Federico Vaga
2017-07-12 17:20       ` Federico Vaga
2017-07-12 18:02         ` Robin Murphy
     [not found]           ` <9273b2ab-2648-63f7-fe0f-a4462b4e4062-5wv7dgnIgG8@public.gmane.org>
2017-07-13  8:43             ` Federico Vaga [this message]
2017-08-11  9:35               ` Federico Vaga

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=22729074.Vd8Fat30YZ@harkonnen \
    --to=federico.vaga-vimsii5odouona0d6jmura@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=robin.murphy-5wv7dgnIgG8@public.gmane.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.