Thread (37 messages) 37 messages, 9 authors, 2025-08-05

Re: [PATCH 0/8] dma-mapping: migrate to physical address-based API

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2025-08-05 15:36:09
Also in: linux-doc, linux-iommu, linux-mm, linux-trace-kernel, lkml, virtualization

On Mon, Aug 04, 2025 at 04:37:56AM +0100, Matthew Wilcox wrote:
On Sun, Aug 03, 2025 at 12:59:06PM -0300, Jason Gunthorpe wrote:
quoted
Matthew, do you think it makes sense to introduce types to make this
clearer? We have two kinds of values that a phys_addr_t can store -
something compatible with kmap_XX_phys(), and something that isn't.
I was with you up until this point.  And then you said "What if we have
a raccoon that isn't a raccoon" and my brain derailed.
I though it was clear..

   kmap_local_pfn(phys >> PAGE_SHIFT)
   phys_to_virt(phys)

Does not work for all values of phys. It definately illegal for
non-cachable MMIO. Agree?

There is a subset of phys that is cachable and has struct page that is
usable with kmap_local_pfn()/etc

phys is always this:
- CPU untranslated.  This is the "physical" address.  Physical address
  0 is what the CPU sees when it drives zeroes on the memory bus.
But that is a pure HW perspective. It doesn't say which of our SW APIs
are allowed to use this address.

We have callchains in DMA API land that want to do a kmap at the
bottom. It would be nice to mark the whole call chain that the
phys_addr being passed around is actually required to be kmappable.

Because if you pass a non-kmappable MMIO backed phys it will explode
in some way on some platforms.
quoted
We clearly have these two different ideas floating around in code,
page tables, etc.
No.  No, we don't.  I've never heard of this asininity before.
Welcome to the fun world of cachable and non-cachable memory.

Consider, today we can create struct pages of type
MEMORY_DEVICE_PCI_P2PDMA for non-cachable MMIO. I think today you
"can" use kmap to establish a cachable mapping in the vmap.

But it is *illegal* to establish a cachable CPU mapping of MMIO. Archs
are free to MCE if you do this - speculative cache line load of MMIO
can just error in HW inside the interconnect.

So, the phys_addr is always a "CPU untranslated physical address" but
the cachable/non-cachable cases, or DRAM vs MMIO, are sometimes
semantically very different things for the SW!

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help