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
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.
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?
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.h...
It contains the LPAE and virtualisation extensions.
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.h...
It contains the LPAE and virtualisation extensions.
-- Catalin
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
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).
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
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.
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?
-- Viresh
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.
On Feb 20, 2012 11:27 PM, "Russell King - ARM Linux" linux@arm.linux.org.uk wrote:
I hope it's now clear why we need to run over the buffer twice.
Thanks Russell. Got it now.
-- Viresh
-
Catalin Marinas -
Russell King - ARM Linux -
viresh kumar