Query: Multiple Mappings to Mem and ARMV6+

Query: Multiple Mappings to Mem and ARMV6+

[viresh kumar]

Hi Guys,

Sorry for starting the long old thread again, but i have to start it as i
was a bit confused. :(

We know that we can't have multiple mappings with different attributes
to the same physical memory on ARMv6+ machines due to speculative
prefetch.

So, we have following kind of mappings in kernel now (please correct me
if i am wrong):
- Low Mem: Mapped at boot time to - Normal Cacheable - Bufferable
- ioremap() - blocked on Low Mem, so that we don't create Device type mapping
to same mem
- dma_alloc_coherent() and others:
         - Without DMA_MEM_BUFFERABLE selected - gives strongly ordered mem
          (i.e. Non cacheable - Non Bufferable)
         - With DMA_MEM_BUFFERABLE selected - gives Normal - Non cacheable -
           Bufferable mapping
         - Maybe some other too...

I have a doubt with the last mapping mentioned above. We have two mappings
possibly to the same physical memory, with different attributes: One
is Cacheable
and other one is not.

Is this allowed by ARM? Because the patch in which Russell blocked ioremap on
Low Mem, he clearly mentioned that these attributes are also important and they
should be same.

Sorry if i am missing something :)

--
viresh

Query: Multiple Mappings to Mem and ARMV6+

[Catalin Marinas]

On Thu, Feb 16, 2012 at 04:41:02PM +0000, viresh kumar wrote:
> Sorry for starting the long old thread again, but i have to start it as i
> was a bit confused. :(
> 
> We know that we can't have multiple mappings with different attributes
> to the same physical memory on ARMv6+ machines due to speculative
> prefetch.
> 
> So, we have following kind of mappings in kernel now (please correct me
> if i am wrong):
> - Low Mem: Mapped at boot time to - Normal Cacheable - Bufferable
> - ioremap() - blocked on Low Mem, so that we don't create Device type mapping
> to same mem
> - dma_alloc_coherent() and others:
>          - Without DMA_MEM_BUFFERABLE selected - gives strongly ordered mem
>           (i.e. Non cacheable - Non Bufferable)
>          - With DMA_MEM_BUFFERABLE selected - gives Normal - Non cacheable -
>            Bufferable mapping
>          - Maybe some other too...
> 
> I have a doubt with the last mapping mentioned above. We have two
> mappings possibly to the same physical memory, with different
> attributes: One is Cacheable and other one is not.
> 
> Is this allowed by ARM? Because the patch in which Russell blocked
> ioremap on Low Mem, he clearly mentioned that these attributes are
> also important and they should be same.

Section A3.5.7 in the latest ARM ARM (revC) clarifies the mismatched
memory attributes (more precise compared to the original "unpredictable"
statement, though the description there is not an easy read). While
changes to the ARM ARM do not apply to already implemented processors,
to my knowledge all existing cores comply with the new ARM ARM
description.

To summarise, if you mix Normal with Device or SO memory, you only get
the guarantees of the Normal memory (e.g. early write acknowledgement,
write buffer gathering, speculative accesses), so it's not recommended.
If you mix Normal Cacheable with Normal Non-cacheable, you need to make
sure that the cacheable mapping does not have any dirty cache lines that
could be evicted. Additionally, if you read the buffer through the
cacheable mapping later, you need to invalidate it first in case cache
lines have been speculatively fetched. The ARM ARM definition however
guarantees that accesses through the Non-cacheable mapping does not hit
any cache lines (brought in via the Cacheable mapping).

So regarding your ioremap() lowmem, even if Linux allowed you to do that
you wouldn't get the guarantees of the Device memory.

-- 
Catalin

Query: Multiple Mappings to Mem and ARMV6+

[Russell King - ARM Linux]

On Thu, Feb 16, 2012 at 05:15:20PM +0000, Catalin Marinas wrote:
> On Thu, Feb 16, 2012 at 04:41:02PM +0000, viresh kumar wrote:
> > Sorry for starting the long old thread again, but i have to start it as i
> > was a bit confused. :(
> > 
> > We know that we can't have multiple mappings with different attributes
> > to the same physical memory on ARMv6+ machines due to speculative
> > prefetch.
> > 
> > So, we have following kind of mappings in kernel now (please correct me
> > if i am wrong):
> > - Low Mem: Mapped at boot time to - Normal Cacheable - Bufferable
> > - ioremap() - blocked on Low Mem, so that we don't create Device type mapping
> > to same mem
> > - dma_alloc_coherent() and others:
> >          - Without DMA_MEM_BUFFERABLE selected - gives strongly ordered mem
> >           (i.e. Non cacheable - Non Bufferable)
> >          - With DMA_MEM_BUFFERABLE selected - gives Normal - Non cacheable -
> >            Bufferable mapping
> >          - Maybe some other too...
> > 
> > I have a doubt with the last mapping mentioned above. We have two
> > mappings possibly to the same physical memory, with different
> > attributes: One is Cacheable and other one is not.
> > 
> > Is this allowed by ARM? Because the patch in which Russell blocked
> > ioremap on Low Mem, he clearly mentioned that these attributes are
> > also important and they should be same.
> 
> Section A3.5.7 in the latest ARM ARM (revC) clarifies the mismatched

There's a new version?

Query: Multiple Mappings to Mem and ARMV6+

[Catalin Marinas]

On Thu, Feb 16, 2012 at 05:22:42PM +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 16, 2012 at 05:15:20PM +0000, Catalin Marinas wrote:
> > On Thu, Feb 16, 2012 at 04:41:02PM +0000, viresh kumar wrote:
> > > Sorry for starting the long old thread again, but i have to start it as i
> > > was a bit confused. :(
> > > 
> > > We know that we can't have multiple mappings with different attributes
> > > to the same physical memory on ARMv6+ machines due to speculative
> > > prefetch.
> > > 
> > > So, we have following kind of mappings in kernel now (please correct me
> > > if i am wrong):
> > > - Low Mem: Mapped at boot time to - Normal Cacheable - Bufferable
> > > - ioremap() - blocked on Low Mem, so that we don't create Device type mapping
> > > to same mem
> > > - dma_alloc_coherent() and others:
> > >          - Without DMA_MEM_BUFFERABLE selected - gives strongly ordered mem
> > >           (i.e. Non cacheable - Non Bufferable)
> > >          - With DMA_MEM_BUFFERABLE selected - gives Normal - Non cacheable -
> > >            Bufferable mapping
> > >          - Maybe some other too...
> > > 
> > > I have a doubt with the last mapping mentioned above. We have two
> > > mappings possibly to the same physical memory, with different
> > > attributes: One is Cacheable and other one is not.
> > > 
> > > Is this allowed by ARM? Because the patch in which Russell blocked
> > > ioremap on Low Mem, he clearly mentioned that these attributes are
> > > also important and they should be same.
> > 
> > Section A3.5.7 in the latest ARM ARM (revC) clarifies the mismatched
> 
> There's a new version?

Rev C has been available for a while. I thought you got it already:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406c/index.html

It contains the LPAE and virtualisation extensions.

-- 
Catalin

Query: Multiple Mappings to Mem and ARMV6+

[Russell King - ARM Linux]

On Thu, Feb 16, 2012 at 05:29:28PM +0000, Catalin Marinas wrote:
> On Thu, Feb 16, 2012 at 05:22:42PM +0000, Russell King - ARM Linux wrote:
> > On Thu, Feb 16, 2012 at 05:15:20PM +0000, Catalin Marinas wrote:
> > > On Thu, Feb 16, 2012 at 04:41:02PM +0000, viresh kumar wrote:
> > > > Sorry for starting the long old thread again, but i have to start it as i
> > > > was a bit confused. :(
> > > > 
> > > > We know that we can't have multiple mappings with different attributes
> > > > to the same physical memory on ARMv6+ machines due to speculative
> > > > prefetch.
> > > > 
> > > > So, we have following kind of mappings in kernel now (please correct me
> > > > if i am wrong):
> > > > - Low Mem: Mapped at boot time to - Normal Cacheable - Bufferable
> > > > - ioremap() - blocked on Low Mem, so that we don't create Device type mapping
> > > > to same mem
> > > > - dma_alloc_coherent() and others:
> > > >          - Without DMA_MEM_BUFFERABLE selected - gives strongly ordered mem
> > > >           (i.e. Non cacheable - Non Bufferable)
> > > >          - With DMA_MEM_BUFFERABLE selected - gives Normal - Non cacheable -
> > > >            Bufferable mapping
> > > >          - Maybe some other too...
> > > > 
> > > > I have a doubt with the last mapping mentioned above. We have two
> > > > mappings possibly to the same physical memory, with different
> > > > attributes: One is Cacheable and other one is not.
> > > > 
> > > > Is this allowed by ARM? Because the patch in which Russell blocked
> > > > ioremap on Low Mem, he clearly mentioned that these attributes are
> > > > also important and they should be same.
> > > 
> > > Section A3.5.7 in the latest ARM ARM (revC) clarifies the mismatched
> > 
> > There's a new version?
> 
> Rev C has been available for a while. I thought you got it already:

No, if no one tells me when a new version is available, then, unless I
waste time regularly polling the website below, I have no way to know.

> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406c/index.html
> 
> It contains the LPAE and virtualisation extensions.
> 
> -- 
> Catalin

Query: Multiple Mappings to Mem and ARMV6+

[viresh kumar]

On Thu, Feb 16, 2012 at 9:15 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> To summarise, if you mix Normal with Device or SO memory, you only get
> the guarantees of the Normal memory (e.g. early write acknowledgement,
> write buffer gathering, speculative accesses), so it's not recommended.
> If you mix Normal Cacheable with Normal Non-cacheable, you need to make
> sure that the cacheable mapping does not have any dirty cache lines that
> could be evicted. Additionally, if you read the buffer through the
> cacheable mapping later, you need to invalidate it first in case cache
> lines have been speculatively fetched. The ARM ARM definition however
> guarantees that accesses through the Non-cacheable mapping does not hit
> any cache lines (brought in via the Cacheable mapping).

I don't know if i understood correctly the earlier mails over the list, but with
speculative writes to Normal Cacheable Memory (Low Mem), we can still
enter an undefined state if we have separate kind of mapping as we have in
dma_alloc_*() and low mem.

Or

Who is responsible here to take care of cleaning and invalidate cached low
mem mappings in case of speculative writes?

--
viresh

Query: Multiple Mappings to Mem and ARMV6+

[Catalin Marinas]

On Thu, Feb 16, 2012 at 05:37:02PM +0000, viresh kumar wrote:
> On Thu, Feb 16, 2012 at 9:15 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > To summarise, if you mix Normal with Device or SO memory, you only get
> > the guarantees of the Normal memory (e.g. early write acknowledgement,
> > write buffer gathering, speculative accesses), so it's not recommended.
> > If you mix Normal Cacheable with Normal Non-cacheable, you need to make
> > sure that the cacheable mapping does not have any dirty cache lines that
> > could be evicted. Additionally, if you read the buffer through the
> > cacheable mapping later, you need to invalidate it first in case cache
> > lines have been speculatively fetched. The ARM ARM definition however
> > guarantees that accesses through the Non-cacheable mapping does not hit
> > any cache lines (brought in via the Cacheable mapping).
> 
> I don't know if i understood correctly the earlier mails over the list, but with
> speculative writes to Normal Cacheable Memory (Low Mem), we can still
> enter an undefined state if we have separate kind of mapping as we have in
> dma_alloc_*() and low mem.
> 
> Or
> 
> Who is responsible here to take care of cleaning and invalidate cached low
> mem mappings in case of speculative writes?

The DMA API implementation on ARM takes care of the cache cleaning and
invalidating.

BTW, I would say cache evictions rather than speculative writes as the
latter is something else and ARM processors don't do it (only
speculative reads).

-- 
Catalin

Query: Multiple Mappings to Mem and ARMV6+

[viresh kumar]

On Thu, Feb 16, 2012 at 9:48 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> The DMA API implementation on ARM takes care of the cache cleaning and
> invalidating.
>

I believe that this is the reason why we have cache re-invalidation
(we invalidated
it in dma_map_*() earlier) in dma_unmap_*() calls for ARMv6+ for
DMA_FROM_DEVICE.
Am i Correct?

> BTW, I would say cache evictions rather than speculative writes as the
> latter is something else and ARM processors don't do it (only
> speculative reads).

Oops!! Sorry for the wrong words :(

--
viresh

Query: Multiple Mappings to Mem and ARMV6+

[Catalin Marinas]

On 16 February 2012 18:14, viresh kumar <viresh.linux@gmail.com> wrote:
> On Thu, Feb 16, 2012 at 9:48 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> The DMA API implementation on ARM takes care of the cache cleaning and
>> invalidating.
>
> I believe that this is the reason why we have cache re-invalidation
> (we invalidated
> it in dma_map_*() earlier) in dma_unmap_*() calls for ARMv6+ for
> DMA_FROM_DEVICE.
> Am i Correct?

Yes.

-- 
Catalin

Query: Multiple Mappings to Mem and ARMV6+

[Russell King - ARM Linux]

On Mon, Feb 20, 2012 at 09:48:56AM -0800, viresh kumar wrote:
> On Feb 20, 2012 4:31 PM, "Catalin Marinas" <catalin.marinas@arm.com> wrote:
> >
> > On 16 February 2012 18:14, viresh kumar <viresh.linux@gmail.com> wrote:
> > > On Thu, Feb 16, 2012 at 9:48 AM, Catalin Marinas
> > > <catalin.marinas@arm.com> wrote:
> > >> The DMA API implementation on ARM takes care of the cache cleaning and
> > >> invalidating.
> > >
> > > I believe that this is the reason why we have cache re-invalidation
> > > (we invalidated
> > > it in dma_map_*() earlier) in dma_unmap_*() calls for ARMv6+ for
> > > DMA_FROM_DEVICE.
> > > Am i Correct?
> >
> > Yes.
> >
> 
> But why isn't keeping only the second one sufficient? Why don't we remove
> it from dma_map_* routines?

Please don't think for a moment that anyone likes the idea of having to
walk over the cache twice for every DMA operation.  We don't.  But I can
assure you that it's very very necessary.

The first run through the affected cache lines on dma_map_*() is there
to get rid of any cache lines for the buffer which may be marked 'dirty'.
A dirty cache line can be evicted (written back) to memory at _any_ time.
If this occurs while the DMA controller is reading data from a device,
the results depend on the order which the particular cache line is written
by the DMA controller, and by the cache line eviction.

If the cache line eviction happens after the DMA controller has written,
the DMA'd data will be overwritten by old stale data.

So, we must get rid of these dirty cache lines.  We can do that either
by cleaning the cache lines or invalidating them.  We chose to invalidate
them because it makes very little difference.

For the case where the DMA controller needs to read from memory, we
obviously have to ensure that all data is pushed out of the cache for it
to be visible to the DMA controller.  For this case, merely cleaning the
cache is sufficient.

The second run through the affected cache lines is to prevent speculative
prefetches occuring while the DMA controller is on operation, which could
result in old data (before the DMA controller has written its data) being
read by the CPU, resulting again in old stale data.

I hope it's now clear why we need to run over the buffer twice.