lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c855a4f9-4a50-4e02-9ac6-372abe7da730@infradead.org>
Date: Thu, 14 Aug 2025 10:37:22 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Leon Romanovsky <leon@...nel.org>,
 Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Leon Romanovsky <leonro@...dia.com>, Jason Gunthorpe <jgg@...dia.com>,
 Abdiel Janulgue <abdiel.janulgue@...il.com>,
 Alexander Potapenko <glider@...gle.com>, Alex Gaynor
 <alex.gaynor@...il.com>, Andrew Morton <akpm@...ux-foundation.org>,
 Christoph Hellwig <hch@....de>, Danilo Krummrich <dakr@...nel.org>,
 iommu@...ts.linux.dev, Jason Wang <jasowang@...hat.com>,
 Jens Axboe <axboe@...nel.dk>, Joerg Roedel <joro@...tes.org>,
 Jonathan Corbet <corbet@....net>, Juergen Gross <jgross@...e.com>,
 kasan-dev@...glegroups.com, Keith Busch <kbusch@...nel.org>,
 linux-block@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linux-nvme@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
 linux-trace-kernel@...r.kernel.org, Madhavan Srinivasan
 <maddy@...ux.ibm.com>, Masami Hiramatsu <mhiramat@...nel.org>,
 Michael Ellerman <mpe@...erman.id.au>, "Michael S. Tsirkin"
 <mst@...hat.com>, Miguel Ojeda <ojeda@...nel.org>,
 Robin Murphy <robin.murphy@....com>, rust-for-linux@...r.kernel.org,
 Sagi Grimberg <sagi@...mberg.me>, Stefano Stabellini
 <sstabellini@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
 virtualization@...ts.linux.dev, Will Deacon <will@...nel.org>,
 xen-devel@...ts.xenproject.org
Subject: Re: [PATCH v2 01/16] dma-mapping: introduce new DMA attribute to
 indicate MMIO memory

Hi Leon,

On 8/14/25 3:13 AM, Leon Romanovsky wrote:
> diff --git a/Documentation/core-api/dma-attributes.rst b/Documentation/core-api/dma-attributes.rst
> index 1887d92e8e92..58a1528a9bb9 100644
> --- a/Documentation/core-api/dma-attributes.rst
> +++ b/Documentation/core-api/dma-attributes.rst
> @@ -130,3 +130,21 @@ accesses to DMA buffers in both privileged "supervisor" and unprivileged
>  subsystem that the buffer is fully accessible at the elevated privilege
>  level (and ideally inaccessible or at least read-only at the
>  lesser-privileged levels).
> +
> +DMA_ATTR_MMIO
> +-------------
> +
> +This attribute indicates the physical address is not normal system
> +memory. It may not be used with kmap*()/phys_to_virt()/phys_to_page()
> +functions, it may not be cachable, and access using CPU load/store

Usually "cacheable" (git grep -w cacheable counts 1042 hits vs.
55 hits for "cachable"). And the $internet agrees.

> +instructions may not be allowed.
> +
> +Usually this will be used to describe MMIO addresses, or other non

non-cacheable

> +cachable register addresses. When DMA mapping this sort of address we

> +call the operation Peer to Peer as a one device is DMA'ing to another
> +device. For PCI devices the p2pdma APIs must be used to determine if
> +DMA_ATTR_MMIO is appropriate.
> +
> +For architectures that require cache flushing for DMA coherence
> +DMA_ATTR_MMIO will not perform any cache flushing. The address
> +provided must never be mapped cachable into the CPU.
again.

thanks.
-- 
~Randy


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ