All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu@mediatek.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Thierry Reding <treding@nvidia.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Robin Murphy <Robin.Murphy@arm.com>,
	Daniel Kurtz <djkurtz@google.com>, Tomasz Figa <tfiga@google.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Rob Herring <robh+dt@kernel.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"linux-mediatek@lists.infradead.org" 
	<linux-mediatek@lists.infradead.org>,
	Sasha Hauer <kernel@pengutronix.de>,
	"srv_heupstream@mediatek.com" <srv_heupstream@mediatek.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"pebolle@tiscali.nl" <pebolle@tiscali.nl>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"mitchelh@codeaurora.org" <mitchelh@codeaurora.org>,
	"cloud.chou@mediatek.com" <cloud.chou@mediatek.com>,
	"frederic.chen@mediatek.com" <frederic.chen@mediatek.com>
Subject: Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
Date: Thu, 17 Sep 2015 10:38:19 +0800	[thread overview]
Message-ID: <1442457499.8145.23.camel@mhfsdcap03> (raw)
In-Reply-To: <20150916125535.GI28771@arm.com>

On Wed, 2015-09-16 at 13:55 +0100, Will Deacon wrote:
> Hello Yong,
> 
> On Mon, Sep 14, 2015 at 01:25:00PM +0100, Yong Wu wrote:
> > On Tue, 2015-07-21 at 18:11 +0100, Will Deacon wrote:
> > > > +       ret = _arm_short_map(data, iova, paddr, pgdprot, pteprot, large);
> > > > +
> > > > +       tlb->tlb_add_flush(iova, size, true, data->iop.cookie);
> > > > +       tlb->tlb_sync(data->iop.cookie);
> > > 
> > > In _arm_short_map, it looks like you can only go from invalid -> valid,
> > > so why do you need to flush the TLB here?
> > 
> > Hi Will,
> >    Here is about flush-tlb after map iova, I have deleted it in v4
> > following this suggestion. But We meet a problem about it.
> 
> Ok.
> 
> > Take a example with JPEG. the test steps is:
> > a).JPEG HW decode a picture with the source iova,like 0xfd780000.
> > b).JPEG HW decode done, It will unmap the iova(write 0 in pagetable and
> > flush tlb).
> > c).JPEG HW decode the second picture, whose source iova is also
> > 0xfd780000.
> >    Then our HW maybe fail due to it will auto prefetch, It may prefecth
> > between the step b) and c). then the HW may fetch the pagetable content
> > which has been unmapped in step b). then the HW will get the iova's
> > physical address is 0, It will translation fault!
> 
> Oh no! So-called "negative caching" is certainly prohibited by the ARM
> architecture, but if you've built it then we can probably work around it
> as an additional quirk. I assume the prefetcher stops prefetching when
> it sees an invalid descriptor?

Yes, If it's a invalid descriptor, the HW will stop prefetch.

> 
> >     So I think our HW need flush-tlb after map iova. Could we add a
> > QUIRK like "IO_PGTABLE_QUIRK_AUTO_PREFETCH_ENABLE" for it?
> > If it's not allowed, we will have to add this in our internal function
> > mtk_iommu_map of mtk_iommu.c.
> 
> Actually, this type of quirk is ringing bells with me (I think another
> IOMMU needed something similar in the past), so maybe just add
> IO_PGTABLE_QUIRK_TLBI_ON_MAP?

Thanks. I will add it like:
//=====================
ret = _arm_short_map(data, iova, paddr, pgdprot, pteprot, large);

if (data->iop.cfg.quirk & IO_PGTABLE_QUIRK_TLBI_ON_MAP) {
	tlb->tlb_add_flush(iova, size, true, data->iop.cookie);
	tlb->tlb_sync(data->iop.cookie);
}
//======================
It will flush-tlb every time after map-iova. then the HW will fetch the
new PA from the dram.

> 
> Will



WARNING: multiple messages have this Message-ID (diff)
From: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
	Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
	"cloud.chou-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org"
	<cloud.chou-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"frederic.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org"
	<frederic.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"arnd-r2nGTMty4D4@public.gmane.org"
	<arnd-r2nGTMty4D4@public.gmane.org>,
	Tomasz Figa <tfiga-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Matthias Brugger
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org"
	<pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>,
	Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org"
	<srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Daniel Kurtz <djkurtz-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Sasha Hauer <kernel@pen>
Subject: Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
Date: Thu, 17 Sep 2015 10:38:19 +0800	[thread overview]
Message-ID: <1442457499.8145.23.camel@mhfsdcap03> (raw)
In-Reply-To: <20150916125535.GI28771-5wv7dgnIgG8@public.gmane.org>

On Wed, 2015-09-16 at 13:55 +0100, Will Deacon wrote:
> Hello Yong,
> 
> On Mon, Sep 14, 2015 at 01:25:00PM +0100, Yong Wu wrote:
> > On Tue, 2015-07-21 at 18:11 +0100, Will Deacon wrote:
> > > > +       ret = _arm_short_map(data, iova, paddr, pgdprot, pteprot, large);
> > > > +
> > > > +       tlb->tlb_add_flush(iova, size, true, data->iop.cookie);
> > > > +       tlb->tlb_sync(data->iop.cookie);
> > > 
> > > In _arm_short_map, it looks like you can only go from invalid -> valid,
> > > so why do you need to flush the TLB here?
> > 
> > Hi Will,
> >    Here is about flush-tlb after map iova, I have deleted it in v4
> > following this suggestion. But We meet a problem about it.
> 
> Ok.
> 
> > Take a example with JPEG. the test steps is:
> > a).JPEG HW decode a picture with the source iova,like 0xfd780000.
> > b).JPEG HW decode done, It will unmap the iova(write 0 in pagetable and
> > flush tlb).
> > c).JPEG HW decode the second picture, whose source iova is also
> > 0xfd780000.
> >    Then our HW maybe fail due to it will auto prefetch, It may prefecth
> > between the step b) and c). then the HW may fetch the pagetable content
> > which has been unmapped in step b). then the HW will get the iova's
> > physical address is 0, It will translation fault!
> 
> Oh no! So-called "negative caching" is certainly prohibited by the ARM
> architecture, but if you've built it then we can probably work around it
> as an additional quirk. I assume the prefetcher stops prefetching when
> it sees an invalid descriptor?

Yes, If it's a invalid descriptor, the HW will stop prefetch.

> 
> >     So I think our HW need flush-tlb after map iova. Could we add a
> > QUIRK like "IO_PGTABLE_QUIRK_AUTO_PREFETCH_ENABLE" for it?
> > If it's not allowed, we will have to add this in our internal function
> > mtk_iommu_map of mtk_iommu.c.
> 
> Actually, this type of quirk is ringing bells with me (I think another
> IOMMU needed something similar in the past), so maybe just add
> IO_PGTABLE_QUIRK_TLBI_ON_MAP?

Thanks. I will add it like:
//=====================
ret = _arm_short_map(data, iova, paddr, pgdprot, pteprot, large);

if (data->iop.cfg.quirk & IO_PGTABLE_QUIRK_TLBI_ON_MAP) {
	tlb->tlb_add_flush(iova, size, true, data->iop.cookie);
	tlb->tlb_sync(data->iop.cookie);
}
//======================
It will flush-tlb every time after map-iova. then the HW will fetch the
new PA from the dram.

> 
> Will

WARNING: multiple messages have this Message-ID (diff)
From: yong.wu@mediatek.com (Yong Wu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.
Date: Thu, 17 Sep 2015 10:38:19 +0800	[thread overview]
Message-ID: <1442457499.8145.23.camel@mhfsdcap03> (raw)
In-Reply-To: <20150916125535.GI28771@arm.com>

On Wed, 2015-09-16 at 13:55 +0100, Will Deacon wrote:
> Hello Yong,
> 
> On Mon, Sep 14, 2015 at 01:25:00PM +0100, Yong Wu wrote:
> > On Tue, 2015-07-21 at 18:11 +0100, Will Deacon wrote:
> > > > +       ret = _arm_short_map(data, iova, paddr, pgdprot, pteprot, large);
> > > > +
> > > > +       tlb->tlb_add_flush(iova, size, true, data->iop.cookie);
> > > > +       tlb->tlb_sync(data->iop.cookie);
> > > 
> > > In _arm_short_map, it looks like you can only go from invalid -> valid,
> > > so why do you need to flush the TLB here?
> > 
> > Hi Will,
> >    Here is about flush-tlb after map iova, I have deleted it in v4
> > following this suggestion. But We meet a problem about it.
> 
> Ok.
> 
> > Take a example with JPEG. the test steps is:
> > a).JPEG HW decode a picture with the source iova,like 0xfd780000.
> > b).JPEG HW decode done, It will unmap the iova(write 0 in pagetable and
> > flush tlb).
> > c).JPEG HW decode the second picture, whose source iova is also
> > 0xfd780000.
> >    Then our HW maybe fail due to it will auto prefetch, It may prefecth
> > between the step b) and c). then the HW may fetch the pagetable content
> > which has been unmapped in step b). then the HW will get the iova's
> > physical address is 0, It will translation fault!
> 
> Oh no! So-called "negative caching" is certainly prohibited by the ARM
> architecture, but if you've built it then we can probably work around it
> as an additional quirk. I assume the prefetcher stops prefetching when
> it sees an invalid descriptor?

Yes, If it's a invalid descriptor, the HW will stop prefetch.

> 
> >     So I think our HW need flush-tlb after map iova. Could we add a
> > QUIRK like "IO_PGTABLE_QUIRK_AUTO_PREFETCH_ENABLE" for it?
> > If it's not allowed, we will have to add this in our internal function
> > mtk_iommu_map of mtk_iommu.c.
> 
> Actually, this type of quirk is ringing bells with me (I think another
> IOMMU needed something similar in the past), so maybe just add
> IO_PGTABLE_QUIRK_TLBI_ON_MAP?

Thanks. I will add it like:
//=====================
ret = _arm_short_map(data, iova, paddr, pgdprot, pteprot, large);

if (data->iop.cfg.quirk & IO_PGTABLE_QUIRK_TLBI_ON_MAP) {
	tlb->tlb_add_flush(iova, size, true, data->iop.cookie);
	tlb->tlb_sync(data->iop.cookie);
}
//======================
It will flush-tlb every time after map-iova. then the HW will fetch the
new PA from the dram.

> 
> Will

  reply	other threads:[~2015-09-17  2:38 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16  9:04 [PATCH v3 0/6] MT8173 IOMMU SUPPORT Yong Wu
2015-07-16  9:04 ` Yong Wu
2015-07-16  9:04 ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 1/6] dt-bindings: iommu: Add binding for mediatek IOMMU Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 2/6] dt-bindings: mediatek: Add smi dts binding Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-21 17:11   ` Will Deacon
2015-07-21 17:11     ` Will Deacon
2015-07-21 17:11     ` Will Deacon
2015-07-24  5:24     ` Yong Wu
2015-07-24  5:24       ` Yong Wu
2015-07-24  5:24       ` Yong Wu
2015-07-24 16:53       ` Will Deacon
2015-07-24 16:53         ` Will Deacon
2015-07-24 16:53         ` Will Deacon
2015-07-27  4:21         ` Yong Wu
2015-07-27  4:21           ` Yong Wu
2015-07-27  4:21           ` Yong Wu
2015-07-27 14:05           ` Robin Murphy
2015-07-27 14:05             ` Robin Murphy
2015-07-27 14:05             ` Robin Murphy
2015-07-27 14:11             ` Will Deacon
2015-07-27 14:11               ` Will Deacon
2015-07-27 14:11               ` Will Deacon
2015-07-28  5:08               ` Yong Wu
2015-07-28  5:08                 ` Yong Wu
2015-07-28  5:08                 ` Yong Wu
2015-07-28 11:00                 ` Will Deacon
2015-07-28 11:00                   ` Will Deacon
2015-07-28 11:00                   ` Will Deacon
2015-07-28 13:37                   ` Yong Wu
2015-07-28 13:37                     ` Yong Wu
2015-07-28 13:37                     ` Yong Wu
2015-07-28 13:47                     ` Will Deacon
2015-07-28 13:47                       ` Will Deacon
2015-07-28 13:47                       ` Will Deacon
2015-07-31  7:55           ` Yong Wu
2015-07-31 11:32             ` Will Deacon
2015-07-31 11:32               ` Will Deacon
2015-07-31 11:32               ` Will Deacon
2015-09-14 12:25     ` Yong Wu
2015-09-14 12:25       ` Yong Wu
2015-09-14 12:25       ` Yong Wu
2015-09-16 12:55       ` Will Deacon
2015-09-16 12:55         ` Will Deacon
2015-09-16 12:55         ` Will Deacon
2015-09-17  2:38         ` Yong Wu [this message]
2015-09-17  2:38           ` Yong Wu
2015-09-17  2:38           ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 4/6] memory: mediatek: Add SMI driver Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-21 14:59   ` Will Deacon
2015-07-21 14:59     ` Will Deacon
2015-07-21 14:59     ` Will Deacon
2015-07-24  5:43     ` Yong Wu
2015-07-24  5:43       ` Yong Wu
2015-07-24  5:43       ` Yong Wu
2015-07-24 16:55       ` Will Deacon
2015-07-24 16:55         ` Will Deacon
2015-07-24 16:55         ` Will Deacon
2015-07-27  4:24         ` Yong Wu
2015-07-27  4:24           ` Yong Wu
2015-07-27  4:24           ` Yong Wu
2015-07-27 15:48           ` Will Deacon
2015-07-27 15:48             ` Will Deacon
2015-07-27 15:48             ` Will Deacon
2015-07-27 13:23   ` Robin Murphy
2015-07-27 13:23     ` Robin Murphy
2015-07-27 13:23     ` Robin Murphy
2015-07-27 15:31     ` Russell King - ARM Linux
2015-07-27 15:31       ` Russell King - ARM Linux
2015-07-27 15:31       ` Russell King - ARM Linux
2015-07-27 15:49       ` Robin Murphy
2015-07-27 15:49         ` Robin Murphy
2015-07-27 15:49         ` Robin Murphy
2015-07-29  5:41         ` Yong Wu
2015-07-29  5:41           ` Yong Wu
2015-07-29  5:41           ` Yong Wu
2015-07-29 10:31           ` Will Deacon
2015-07-29 10:31             ` Will Deacon
2015-07-29 10:31             ` Will Deacon
2015-07-29  6:32     ` Yong Wu
2015-07-29  6:32       ` Yong Wu
2015-07-29  6:32       ` Yong Wu
2015-07-16  9:04 ` [PATCH v3 6/6] dts: mt8173: Add iommu/smi nodes for mt8173 Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-16  9:04   ` Yong Wu
2015-07-23 14:40   ` Daniel Kurtz
2015-07-23 14:40     ` Daniel Kurtz
2015-07-23 14:40     ` Daniel Kurtz
2015-07-29  7:29     ` Yong Wu
2015-07-29  7:29       ` Yong Wu
2015-07-29  7:29       ` 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=1442457499.8145.23.camel@mhfsdcap03 \
    --to=yong.wu@mediatek.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=arnd@arndb.de \
    --cc=cloud.chou@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=djkurtz@google.com \
    --cc=frederic.chen@mediatek.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mitchelh@codeaurora.org \
    --cc=pebolle@tiscali.nl \
    --cc=robh+dt@kernel.org \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@google.com \
    --cc=treding@nvidia.com \
    --cc=will.deacon@arm.com \
    /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.