svn commit: r245147 - head/sys/arm/include

[Oleksandr Tymoshenko]

On 2013-01-08, at 7:56 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:

> On Mon, Jan 07, 2013 at 09:06:15PM -0800, Oleksandr Tymoshenko wrote:
>> On 1/7/2013 7:00 PM, Konstantin Belousov wrote:
>>> On Tue, Jan 08, 2013 at 02:40:20AM +0000, Oleksandr Tymoshenko wrote:
>>>> Author: gonzo
>>>> Date: Tue Jan  8 02:40:20 2013
>>>> New Revision: 245147
>>>> URL: http://svnweb.freebsd.org/changeset/base/245147
>>>> 
>>>> Log:
>>>>   Switch default cache type for ARMv6/ARMv7 from write-through to
>>>>   writeback-writeallocate
>>> Could you, please, describe how this is supposed to work.
>>> 
>>> Assume that a process mapped the same file page at two different
>>> addresses, both read-write, and writes to both mappings. Usermode code
>>> does not consider the need to flush caches or synchronize writes into
>>> non-overlapping regions, usually. Would it break, i.e. could the values
>>> appear in the page which were never written to it ?
>> 
>> I might misunderstood question so let me rephrase it:
>> One physical page P, virtual addresses A and B both mapped to it. Two 
>> conditions should
>> be true:
>> 
>> -  if I write word to A+0x200  same value should appear at B+0x200 next 
>> time it is read
>> - If there are no writes to P either through A or B each next read 
>> should yield same result.
> I am more concerned with the following:
> assume that current content in the page is 0x200:u, 0x201:v, and a byte
> x was written at A+0x200, byte y at B+0x201. Is it possible that
> future read of the bytes at A+0x200, A+0x201 (on the same core)
> returns (x, v) ?
    On ARMv7 - no, it's not possible. On ARMv6 - it seems to be possible 
from what I gather. 

>> 
>> These conditions are met for ARMv7 devices for both WT and WBWA caches. 
>> They're PIPT
>> so no aliasing in this case. Up until now I believed that "no aliasing" 
>> is true for all ARM CPUs
>> we target but quick check proved me wrong: ARM1176 on which Raspberry Pi
>> is based is prone to cache aliasing problem. Which might explain memory 
>> corruption
>> easily reproducible under load. Again the problem is not related to 
>> cache type itself but
>> to the lack of handling of this situation in pmap module.
> I am trying to find a way through the ARM ARM and some additional texts.
> Could it be that cache aliasing is only limited to the I-cache on ARM,
> at least for recent cores ?  My concern is hopefully not valid than.
> 
> Hm, it seems, according to the link below, that ARMv6 is affected.

> 
>> 
>> Some info on subject:
>> http://blogs.arm.com/software-enablement/716-page-colouring-on-armv6-and-a-bit-on-armv7/
> 
> This seems to support the idea that mmap does not work on ARM, at least
> for ARMv6. It seems that sf buffers do not obey the arch requirements
> for aliasing as well.
> 
> Thank you for the link.