linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tfiga@google.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] iommu/mediatek: Add mt8173 IOMMU driver
Date: Wed, 15 Apr 2015 16:41:17 +0900	[thread overview]
Message-ID: <CAAFQd5A2FgsbusEbxVVqSeC7hY=Ewe-YbJ7bbvk-SjpSC==xDw@mail.gmail.com> (raw)
In-Reply-To: <1429081567.16400.16.camel@mhfsdcap03>

On Wed, Apr 15, 2015 at 4:06 PM, Yong Wu <yong.wu@mediatek.com> wrote:
> On Wed, 2015-04-15 at 11:20 +0900, Tomasz Figa wrote:
>> On Tue, Apr 14, 2015 at 3:31 PM, Yong Wu <yong.wu@mediatek.com> wrote:
>> >> >>
>> >> >> > +
>> >> >> > +       piommu->protect_va = devm_kmalloc(piommu->dev, MTK_PROTECT_PA_ALIGN*2,
>> >> >>
>> >> >> style: Operators like * should have space on both sides.
>> >> >>
>> >> >> > +                                         GFP_KERNEL);
>> >> >>
>> >> >> Shouldn't dma_alloc_coherent() be used for this?
>> >> >      We don't care the data in it. I think they are the same. Could you
>> >> > help tell me why dma_alloc_coherent may be better.
>> >>
>> >> Can you guarantee that at the time you allocate the memory using
>> >> devm_kmalloc() the memory is not dirty (i.e. some write back data are
>> >> stored in CPU cache) and is not going to be written back in some time,
>> >> overwriting data put there by IOMMU hardware?
>> >>
>> > As I noted in the function "mtk_iommu_hw_init":
>> >
>> >        /* protect memory,HW will write here while translation fault */
>> >        protectpa = __virt_to_phys(piommu->protect_va);
>> >
>> >      We don?t care the content of this buffer, It is ok even though its
>> > data is dirty.
>> >     It seem to be a the protect memory. While a translation fault
>> > happened, The iommu HW will overwrite here instead of writing to the
>> > fault physical address which may be 0 or some random address.
>> >
>>
>> Do you mean that it's just a dummy page for hardware behind the IOMMU
>> to access when the mapping is not available? How would that work with
>> potential on demand paging when the hardware needs to be blocked until
>> the mapping is created?
>>
>> Best regards,
>> Tomasz
>  1. YES
>  2. Sorry. Our iommu HW can not support this right now. The HW can not
> be blocked until the mapping is created.

OK, that explains it. Well, then I guess this is necessary and
contents of that memory don't matter that much. (Although, this might
be a minor security issue, because the faulting hardware would get
access to some data previously stored by kernel code. Not sure how
much of a threat would that be, though.)

>     If the page is not ready, we can not get the physical address, then
> How to fill the pagetable for that memory. I think the dma&iommu may
> guaranty it?

If your hardware can't block until the mapping is created then what
you do currently seems to be the only option. (+/- the missing cache
maintenance at initialization)

Best regards,
Tomasz

  reply	other threads:[~2015-04-15  7:41 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-06 10:48 [RFC PATCH 0/5] MT8173 IOMMU support yong.wu at mediatek.com
2015-03-06 10:48 ` [PATCH 1/5] soc: mediatek: Add SMI driver yong.wu at mediatek.com
2015-03-06 11:30   ` Paul Bolle
2015-03-09 11:57     ` Yong Wu
2015-03-09 17:59       ` Paul Bolle
2015-03-09 21:54         ` Arnd Bergmann
2015-03-10  6:17         ` Yingjoe Chen
2015-03-09  3:26   ` Yingjoe Chen
2015-03-09 21:56     ` Arnd Bergmann
2015-03-10  6:27       ` Yingjoe Chen
2015-03-10  9:05         ` Arnd Bergmann
2015-03-10  9:24       ` Lucas Stach
2015-03-09 11:03   ` Sascha Hauer
2015-03-06 10:48 ` [PATCH 2/5] iommu/mediatek: Add mt8173 IOMMU driver yong.wu at mediatek.com
2015-03-06 10:58   ` Will Deacon
2015-03-09 12:11     ` Yong Wu
2015-03-17 15:14       ` Will Deacon
2015-03-06 17:15   ` Mitchel Humpherys
2015-03-09 12:16     ` Yong Wu
2015-03-09 16:57       ` Mitchel Humpherys
2015-03-08  4:12   ` Tomasz Figa
2015-03-12 14:16     ` Yong Wu
2015-03-09  8:24   ` Daniel Kurtz
2015-03-09 11:11   ` Tomasz Figa
2015-03-09 14:46     ` Yingjoe Chen
2015-03-09 17:00       ` Tomasz Figa
2015-03-10  3:41         ` Yingjoe Chen
2015-03-10  4:06           ` Tomasz Figa
2015-03-11 10:53   ` Tomasz Figa
2015-03-18 11:22     ` Yong Wu
2015-03-20 19:14       ` Robin Murphy
2015-04-14  6:50         ` Yong Wu
2015-03-27  9:41       ` Tomasz Figa
2015-04-14  6:31         ` Yong Wu
2015-04-15  2:20           ` Tomasz Figa
2015-04-15  7:06             ` Yong Wu
2015-04-15  7:41               ` Tomasz Figa [this message]
2015-04-29  6:23         ` Yong Wu
2015-03-06 10:48 ` [PATCH 3/5] dt-bindings: mediatek: Add smi dts binding yong.wu at mediatek.com
2015-03-06 11:13   ` Mark Rutland
2015-03-09 12:55     ` Yong Wu
2015-04-14  9:07     ` Yong Wu
2015-04-14 10:06       ` Mark Rutland
2015-04-14 13:49         ` Yong Wu
2015-04-14 13:55           ` Yong Wu
2015-04-14 13:56           ` Mark Rutland
2015-03-06 14:48   ` Sergei Shtylyov
2015-03-09 12:32     ` Yong Wu
2015-03-06 10:48 ` [PATCH 4/5] dt-bindings: iommu: Add binding for mediatek IOMMU yong.wu at mediatek.com
2015-03-06 11:21   ` Mark Rutland
2015-03-09 11:30     ` Yong Wu
2015-03-06 10:48 ` [PATCH 5/5] dts: mt8173: Add iommu/smi nodes for mt8173 yong.wu at mediatek.com
2015-03-07 15:20   ` Daniel Kurtz
2015-03-09 12:18     ` Yong Wu

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='CAAFQd5A2FgsbusEbxVVqSeC7hY=Ewe-YbJ7bbvk-SjpSC==xDw@mail.gmail.com' \
    --to=tfiga@google.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).