Re: ARCH_DMA_MINALIGN on PA-RISC

[John David Anglin <dave.anglin@bell.net>]

On 2024-07-24 2:17 p.m., Mikulas Patocka wrote:
> Hi
>
> Thanks for fixing the cache aliasing issues on PA-RISC in the commit
> 72d95924ee35c8cd16ef52f912483ee938a34d49.
>
> I think there is still one problem left - and that is ARCH_DMA_MINALIGN.
> Currently, it is 16, which is obviously wrong.
>
> Some comments in the kernel say that PA8900 has L2 cache with 128-byte
Yes, that is correct.  The PA8800 and PA8900 processors have 128-byte cache lines.
Previous PA 2.0 processors have 64-byte lines.
> line size, so I think that ARCH_DMA_MINALIGN should be 128 as well.
>
>
> The question is - can the CPU speculatively mark a cache line as dirty and
> write it back? If yes, we have a big problem - Linux assumes that a part
> of the page may be used for DMA transfer and another part of that page may
> be used for normal cacheable structures. If the PA-RISC CPU speculatively
> prefetched and wrote back a cache line,ove-in it could corrupt the DMA transfer.
I don't believe a CPU can mark a cache line as dirty and write it back.  A CPU can
speculatively read a line if the TLB entry for it is installed and it permits move-in.
Only setting setting the T bit or setting access rights to zero inhibits move-in (see
do_alias macro).  The NO_CACHE bit is another option.

Currently, near all cache flushes are done by removing the TLB entry and then
the page is flushed using a tmpalias flush that inhibits movein. This ensures that the
CPU doesn't speculatively bring lines for the page back into the cache.
>
> If the CPU doesn't speculatively mark cache lines as dirty, then
> increasing ARCH_DMA_MINALIGN would be sufficient solution.
Dave

-- 
John David Anglin  dave.anglin@bell.net