Humor me. This is just in regards to a discussion that we had with a colleague.
It is regarding the Aarch64 architecture, but would probably apply to Intel as well. Say, if we just have a physical address in memory. Can that physical address, or more precisely the physical page in memory, have read/write/execute (protection) attributes, as well as (for ARM) the device type: such as normal or device memory, or cacheability attributes: inner/outershareable, etc.?
My thinking was that those attributes are applied to a virtual address only (during the virtual address translation) and not to a physical address.
The page table has r/w/x and caching attributes for physical addresses. The CPU has no idea whether a given page maps to memory or device. It just puts the address on its address pins, and some device responds.
But does that mean that I can hypothetically set up my page tables to have 2 different virtual addresses to point to the same physical page but with different attributes, say:
page1: r/x - cacheable - normal-memory
page2: w - non-cacheable - device-memory
Yes, that's possible, although not recommended. Confusion can result.
Windbg, in particular, will complain if you try to dump physical address memory with non-matching cache attributes..
And, to repeat myself, "normal-memory" vs "device-memory" is not a page table attribute. The processor has absolutely no idea what's connected to that physical address.
Which bus the memory is attached to. ‘Normal’ memory is attached to (one of) the cpu memory bus(ses). Device memory is attached to some other bus, typically some pci* bus. Other than that, there really isn’t much difference.
Just to be clear, by “confusion” here, Mr. Robert’s means “data corruption” — this is why this mapping (one cached, one not cached) in Windows was prohibited.
My apologizes, guys. Or maybe I'm not phrasing it correctly. Let me try again.
I understand the answers that were posted above from the hardware perspective. I'm asking more from a software side.
Say, if there's a physical address, just by having that physical address a (kernel) piece of software will have no way of knowing if it's a "normal" page of memory, or a "device" memory. Right? To tell that, it needs a virtual address, or a set of page tables that have those device-type attributes, cacheability, shareability, r/w/x and other attributes.
This was my question. Am I correct in my assumption? If not, then I'm probably off and I need to correct my understanding of how it works.
The only kernel software other than the memory manager components that should be directly handling physical addresses is the the device driver that manages the device that provides those memory regions, and then only to acquire virtual addresses for accessing that memory.
The device driver 'knows' it is device memory because the PnP device configuration resource configuration components provided resource data to the device driver identifying the memory regions on the device (and the device programmer's guide also defined these resources.)
Other than configuration, physical addresses should never be used.
No really 'it' doesn't. A pci* device, for example, provides a set of BARs, some (and generally all these days) of which are memory space regions.
But perhaps you might want to describe what problem you are trying to solve, as you seem to be a bit lost in the weeds.
Well, no. Not right. I mean, the Memory Manager knows, right? And the BIOS. Somebody has to assign those physical addresses to the device, right. And what would do that assignment if it wasn’t “a kernel piece of software”?
@Peter_Viscarola_OSR, you're adding new variables to the equation. My question was only when you have a physical address. Nothing else. You don't have the memory manager, or UEFI, or a device driver itself, or any other component. They obviously "know". Again, all I have to make a determination of a normal/device memory type is just a physical address. Can you make that decision based on that alone?
My answer is no. (Which is obviously not the case if I had a virtual address that was mapped to that physical page.)
And yes, it's a thought experiment. I'm not coding anything.
With all due respect, it is not me who is adding to your question. You are introducing new constraints.
You said “a piece of kernel software” — that’s what the Memory Manager is. And the ACPI BIOS. And PnP.
Now, if you meant “Can an arbitrary user write a Windows driver running in kernel mode and using only documented interfaces, that given a physical address can know if that address is associated with device memory or main memory?” … that’s a different question.
The answer to THAT question is even difficult. ISTR that you can query for physical device memory resources. So… maybe.
If you meant “if I write a physical address on a piece of paper can anybody tell me whether that address is for main memory or device memory” it’s still a difficult question. If you know the system type, and the amount of physical memory on the machine, it might very well be possible to deduce whether a given address is likely to be device memory.
Look addresses are addresses. When it gets to the CPU, it's going to execute an instruction like "mov rax, [0xff700390]". It's just a number. The address lookup in the CPU will map that to a physical address, like 0x00001234_00700390. Now, looking at that number, is that device memory or real memory? You can't tell, can you? Neither can the processor. It just puts a read cycle out on its external bus, hoping someone will answer.
OK, thank you both. It was my fault. I wasn't more specific about it.
Now it raises another question: What is the point of that normal/device memory attribute for Arm64? This one is the attribute of the PTE in the page table, so it's a property of a virtual address.
@Tim_Roberts afaik there's no such attribute for the Intel x86/x64 architecture.