Up pose series--memory mapping function under kernel environment

The same is found in other people's code, the author used the mmgetphysicaladdress and mmmapiospace these two functions, have never seen these two functions are also thought to be written by the author. And then I checked the WDK. The original function is a document. The author uses this function to take the address of the cached model I/O to the physical address and then map out the virtual address, although I do not see the meaning of doing so, because for buffered I/O mode, the address given in the IRP is the result of the I/O manager after the replication, no need to do any mapping, I don't know what the author is going to do, but you can learn the use of these two functions.

Physical_address  mmgetphysicaladdress (in    PVOID  baseaddress    );

This return is the direct physical address.

typedef large_integer Physical_address, *pphysical_address;

Visible physical_address is the large_integer.

Take a look at the source of this function, from WRK. Visible is obtained by obtaining a PTE to obtain the physical address. Macro content did not follow up to see, but think about it can know how to implement, is nothing more than the principle of paging mechanism.

1 physical_address2 mmgetphysicaladdress (3 __in PVOID baseaddress4     )5 6 {7 pmmpte Pointerpte;8 physical_address physicaladdress;9 Ten     if(Mi_is_physical_address (baseaddress)) One     { APhysicaladdress.quadpart =MI_CONVERT_PHYSICAL_TO_PFN (baseaddress); -     } -     Else  the     { -  -Pointerpte =migetpdeaddress (baseaddress); -         if(Pointerpte->u.hard.valid = =0)  +         { -Kdprint (("mm:mmgetphysicaladdressfailed Base Address was%p", + baseaddress)); A Zero_large (physicaladdress); at             returnphysicaladdress; -         } -  -         if(Mi_pde_maps_large_page (pointerpte)) -         { -Physicaladdress.quadpart = Mi_get_page_frame_from_pte (pointerpte) + in Migetpteoffset (baseaddress); -         } to         Else  +         { -Pointerpte =migetpteaddress (baseaddress); the  *             if(Pointerpte->u.hard.valid = =0)  $             {Panax NotoginsengKdprint (("mm:mmgetphysicaladdressfailed Base Address was%p", - baseaddress)); the Zero_large (physicaladdress); +                 returnphysicaladdress; A             } thePhysicaladdress.quadpart =Mi_get_page_frame_from_pte (pointerpte); +         } -     } $  $Physicaladdress.quadpart = Physicaladdress.quadpart <<Page_shift; -Physicaladdress.lowpart + =Byte_offset (baseaddress); -  the     returnphysicaladdress; -}

Next look at this function

PVOID   mmmapiospace (    in physical_address  physicaladdress, in    size_t  numberofbytes, in    Memory_caching_type  cachetype    );

It is also a function of a document in the WDK that maps a physical address to a virtual address. The pvoid return value is the resulting virtual address. numberofbytes is the length of the map. So the two functions can be used well, my idea is to get a virtual address in a process corresponding to the physical address, and then in the B process to map this physical address can be used, so as to break through the limits of the independent address space of each process.

Incidentally, for the Windows memory management do not understand the children's shoes can not understand why the physical address is not directly used, because for us is not directly using the physical address, we are usually exposed to a segmented + paging mechanism after the conversion of the virtual address, And the only place that touches the physical address, I think, is the base address of the PDE saved in the CR3 register.

Up pose series--memory mapping function under kernel environment