ARMv7中CONFIG_ARM_DMA_MEM_BUFFERABLE的疑问

arm-linux-gcc

回复 10# lyl19


我觉得armv7应该是仍然有write buffer这个东西的
DDI0388I_cortex_a9_r4p1_trm
DEN0013C_cortex_a_series_PG
这两个文档中都有提到这东西，只是C/B位的作用不再仅仅是armv5时得那些作用了而已
armv5里面C/B位就是简单的控制cacheable bufferable，armv7里面C/B/S和TEX[2:0]搭配起来控制cache writebuffer和armv7新加的东西
DEN0013C_cortex_a_series_PG中的10.7.2有一些描述


我觉得所谓的strong-order   device   normal，他们只是cache   writebuffer   share等的组合效果而已

asuka2001

回复 1# lyl19

config ARM_DMA_MEM_BUFFERABLE
       ......
        help
          Historically, the kernel has used strongly ordered mappings to
          provide DMA coherent memory.  With the advent of ARMv7, mapping
          memory with differing types results in unpredictable behaviour,
          so on these CPUs, this option is forced on.

          Multiple mappings with differing attributes is also unpredictable
          on ARMv6 CPUs, but since they do not have aggressive speculative
          prefetch, no harm appears to occur.

          However, drivers may be missing the necessary barriers for ARMv6,
          and therefore turning this on may result in unpredictable driver
          behaviour.  Therefore, we offer this as an option.

          You are recommended say 'Y' here and debug any affected drivers.


个人见解：为了避免红字提到的情况，所以内核使用 device memory，但是补偿以 memory barrier以保持 dma memorry的 strongly ordered需求！

asuka2001

回复 3# lyl19

个人认为关闭了该选项才是直接使用的 strongly ordered memory。

见内核实现：

#define pgprot_stronglyordered(prot) \
        __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)

asuka2001

回复 9# arm-linux-gcc

我对strong order memory类型的理解
strong order memory是uncacheable + unbufferable + shareable
device memory是uncacheable + bufferable + shareable或uncacheable + unbufferable + unshareable

不管sctlr.tre是0还是1，cache和buffer和share的物理意义仍然就是字面意思

赞同。strong order memory和 device memory只是提法，实际实现还是靠最后是否 cacheable, bufferable！

strong order memory和device memory的区别，应该是和总线竞争时的优先级有关的

spec中提到：
The only architecturally-required difference between Device and Strongly-ordered memory is that:
•a write to Strongly-ordered memory can complete only when it reaches the peripheral or memory component
accessed by the write
•a write to Device memory is permitted to complete before it reaches the peripheral or memory component
accessed by the write.


但是 shareable个人感觉不太理解，请教下：

就实现上而言，processor间应该是通过 MESI协议完成的吧。而 processor与设备间，只要保证 STORE实际抵达 内存或 device，应该就可以了。不知道是否正确？

arm-linux-gcc

1，shareable对于normal memory
MOESI只会对设置了shareable的normal memory区域有效

DDI0406C_arm_architecture_reference_manual中提到：

The memory region attribute fields control the memory type, accesses to the caches, and whether
the memory region is Shareable and therefore is coherent.

Non-shareable Normal memory
For a Normal memory region, the Non-shareable attribute identifies Normal memory that is likely to be accessed
only by a single processor.
A region of Normal memory with the Non-shareable attribute does not have any requirement to make data accesses
by different observers coherent, unless the memory is Non-cacheable.





2，shareable对于strong-order memory和device memory
涉及到总线

DDI0406C_arm_architecture_reference_manual中提到：

For Device memory regions, the significance of shareability is IMPLEMENTATION DEFINED. However, an example
of a system supporting Shareable and Non-shareable Device memory is an implementation that supports both:
• a local bus for its private peripherals
• system peripherals implemented on the main shared system bus.

asuka2001

回复 15# arm-linux-gcc

thanks，非常清楚！

lyl19

Hi 两位

我会去查看一下那两个文档，不过在DDI0406C_arm_architecture_reference_manual，对于TXE[], C, B组合起来的几种memory属性，确实没有bufferable这个属性，不管SCTLR.TRE是否为1，难道这是一个隐含的属性。

看了asuka的描述，这里还是回归到我的两个疑问
1. 真正使能了ARM_DMA_MEM_BUFFERABLE这个宏，带来的影响是使用L_PTE_MT_BUFFERABLE 分配内存，然后io操作是带mb的，而不使能这个宏，带来的影响是使用L_PTE_MT_UNCACHED，然后io操作是不带mb的。
   asuka认为L_PTE_MT_UNCACHED对应的是strong order的，然后不需要mb。但其实在我的系统中，对应下来，L_PTE_MT_UNCACHED是strong的，然后L_PTE_MT_UNCACHED反而是device的。所以我的疑问是
   真正使能ARM_DMA_MEM_BUFFERABLE与否，它对应的内存究竟应该是啥样子的(strong order, device ,normal+noncache)，才允许io操作是否带mb。这里我们不能通过字面意思来判断这个内存的属性，而应该通过TXE, CB的组合来判断。
2. 如果真是是关掉ARM_DMA_MEM_BUFFERABLE， 使用L_PTE_MT_UNCACHED分配到的是strong order类型的memory, 那么IO操作不带mb，这在ARMv7中这是安全的吗？
   这里我还是疑问，因为DDI0406C_arm_architecture_reference_manua中A3.8， Figure A3-5, 我们得知，对strong order类型的memory访问，它是可以保证顺序的，但如果是对不同memory类型的访问，它是不能保证顺序的，
   比如说
   A=LOAD(addr1).
     write32(addr2, A).
     因为A操作的对象addr1是在normal memory, 而write32是对strong order的写，但因为ARM_DMA_MEM_BUFFERABLE关掉了，write32函数不带mb了，现在这个驱动还安全吗？因为我们并不能保证这两条 指令的顺序。

我比较纠结这个问题是因为以前发生过因为这个IO操作是否带mb，而引发驱动出问题，而且花了比较长时间才排察。

不知道两位是否理解了我的意思。

Thanks
Roger

lyl19

回复 12# asuka2001


  “  个人见解：为了避免红字提到的情况，所以内核使用 device memory，但是补偿以 memory barrier以保持 dma memorry的 strongly ordered需求！

个人认为关闭了该选项才是直接使用的 strongly ordered memory。

见内核实现：

#define pgprot_stronglyordered(prot) \
        __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)
”

我也觉得以前ARM在没有CONFIG_ARM_DMA_MEM_BUFFERABLE这个宏的时候，是直接使用的strong order。然后现在ARMv7如果使用其它memory，则应该加上barrier来保证安全。

所以这也是为什么我做了验证，在发现我平台上使能了CONFIG_ARM_DMA_MEM_BUFFERABLE，但是使用的内存依然是strong order，所以我人为去掉了barrier, 结果目前来说正常而且性能提高（因为没了barrier）。

但我疑惑的是，毕竟ARMV7和以前的ARM不同，现在的strong order也可能跟以前不同，现在使用strong order，然后IO操作不带barrier，这样对驱动来说是安全的吗？具体这个疑问请参考我上一个回复。

在我没弄清楚之前，我不想因为一些性能提高就损失稳定性。

Thanks

arm-linux-gcc

lyl19 发表于 2014-03-13 23:01
回复 12# asuka2001

所以这也是为什么我做了验证，在发现我平台上使能了CONFIG_ARM_DMA_MEM_BUFFERABLE，但是使用的内存依然是strong order

你是通过什么判断出打开CONFIG_ARM_DMA_MEM_BUFFERABLE之后，仍然是strong order。

asuka2001

回复 18# lyl19

我的观点是错误的。内核使用 normal nocacheable memory作为 coherent dma memory。

而 memory barrier的作用详见：

commit 79f64dbf68c8a9779a7e9a25e0a9f0217a25b57a
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Wed Jul 28 22:01:55 2010 +0100

    ARM: 6273/1: Add barriers to the I/O accessors if ARM_DMA_MEM_BUFFERABLE

    When the coherent DMA buffers are mapped as Normal Non-cacheable
    (ARM_DMA_MEM_BUFFERABLE enabled), buffer accesses are no longer ordered
    with Device memory accesses causing failures in device drivers that do
    not use the mandatory memory barriers before starting a DMA transfer.
    LKML discussions led to the conclusion that such barriers have to be
    added to the I/O accessors:

    http://thread.gmane.org/gmane.linux.kernel/683509/focus=686153
    http://thread.gmane.org/gmane.linux.ide/46414
    http://thread.gmane.org/gmane.linux.kernel.cross-arch/5250

    This patch introduces a wmb() barrier to the write*() I/O accessors to
    handle the situations where Normal Non-cacheable writes are still in the
    processor (or L2 cache controller) write buffer before a DMA transfer
    command is issued. For the read*() accessors, a rmb() is introduced
    after the I/O to avoid speculative loads where the driver polls for a
    DMA transfer ready bit.

    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>