Well, I appreciate the time Ken and Pavel have taken to attempt to clarify this issue so far.
So, I think most of us are aware of the problem with using MmMapLockedPagesSpecifyCache with the wrong cache type. And I think we also get the (theoretical) problem with MmMapIoSpace (which ignores what you specify as caching type anyhow… but that’s a matter of implementation and not architecture).
However, I’m not sure that I understand the issue with \Device\PhysicalMemory… but I MIGHT have learned something today. Let’s see if I understand correctly what you guys (Ken and Pavel) have been saying:
I hear you saying is that \Device\PhysicalMemory is useless for mapping arbitrary physical pages into kernel virtual address space (such as, ah, to access parts of the BIOS or whatever). Because, even though you open the section and have a handle to it, you don’t “own” (for some value of “own”) the underlying physical memory pages… is that correct?
So, the ONE AND ONLY proper use of \Device\PhysicalMemory is to allow you to get a handle to the section, and then map a view to the PART of that section back to a given user mode process, IF (and only if) the part of the section you map back to user mode is memory that you’ve previously explicitly allocated or referenced through the memory manager.
And this is all simply because we can’t map the page as Uncached or WriteCombined and WriteBack at the same time, because to do so will cause memory corruption (which we all know)… and the Mm doesn’t keep track of this attribute anywhere for arbitrary pages… even though MmMapViewOfSection doesn’t even ALLOW us to specify the caching type?
But… wait… This is where I get confused:
The Mm DOES know the caching type (UC, WC, or WB) of each page of physical memory (the PFN has a pointer to a PTE that maps the page) at any given point in time. And given that when I call MmMapViewOfSection I don’t CARE about the memory caching type, and by making this call the Mm knows that I have a view to a set of pages… he can ensure my view is consistent. So, exactly when can this be a problem, in terms of mapping an arbitrary page from \Device\PhysicalMemory into kernel virtual address space?
If the “owner” frees a given page Mm STILL knows I’ve got the page mapped. If, later, somebody tries to change the mapping (and I’m not sure how common this even IS), the Mm STILL knows what my mapping is and could either (a) silently convert the other reference to my mapping type, or (b) fail the other mapping operation. Because, in the end, UC, WC or WB is in fact only something that we specify or care about for VERY FEW pages, right?
Again… to be clear: I’m not trying to argue. I’m trying to understand WHY this particular proscription is necessary. I am *not* trying to defend the OPs concept of mapping arbitrary pages back to user mode. I’m trying to understand how this works in Mm and why this is an issue. And I feel like I’m missing something.
Peter
OSR