On Sun, Aug 03, 2025 at 12:59:06PM -0300, Jason Gunthorpe wrote: > 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. > This was recently a long discussion in ARM KVM as well which had a > similar confusion that a phys_addr_t was actually two very different > things inside its logic. No. A phys_addr_t is a phys_addr_t. If something's abusing a phys_addr_t to store something entirely different then THAT is what should be using a different type. We've defined what a phys_addr_t is. That was in Documentation/core-api/bus-virt-phys-mapping.rst before Arnd removed it; to excerpt the relevant bit: --- - CPU untranslated. This is the "physical" address. Physical address 0 is what the CPU sees when it drives zeroes on the memory bus. [...] So why do we care about the physical address at all? We do need the physical address in some cases, it's just not very often in normal code. The physical address is needed if you use memory mappings, for example, because the "remap_pfn_range()" mm function wants the physical address of the memory to be remapped as measured in units of pages, a.k.a. the pfn. --- So if somebody is stuffing something else into phys_addr_t, *THAT* is what needs to be fixed, not adding a new sub-type of phys_addr_t for things which are actually phys_addr_t. > 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.
