Wdk tips (10) MDL is a list of memory descriptions (memory descriptor list)

Let's talk about it first. I don't know whether it's for the purpose of showing off or what the bad taste is,ProgramWhen giving a name to your project, you like to play "recursive" tricks. For example, the full name of GNU is not UNIX, and the full name of wine is not emulator. This kind of joke is common in the open-source field, but Microsoft and the people who mix with Microsoft seldom do this. It is unlikely that msnd is a serious product document. MDL is an exception. Let's take a look at how msdn describes MDL:

MDL
An MDL structure is a partially-opaque structure that represents a memory descriptor list (MDL ).

MDL is a type of MDL, which is the same as not mentioned. I felt like this: On a sunny Sunday afternoon, I went to work overtime happily with a little song. My boss fell into my face and said: the customer wants MDL and does not have MDL. They don't have to pay for it, so they need to deal with it. I asked, What is MDL? I am illiterate. I don't understand it, at this time, the boss turned to me a big trick when his anger was full: MDL means MDL doesn't know how to pack and leave on Monday! When I see such a dramatic scene, I can only say: The caster painted three black lines on my left face.

Let's get down to the truth. So what will I do if I want to explain MDL? I will say this:

MDL

MDL provides a mechanism for programmers to manually bind a continuous virtual address to a physical memory address.

Obviously, you need background knowledge about virtual memory before learning about MDL. You Need To Know How virtual addresses are mapped to physical addresses, this part is a bit big. We will talk about it next time, but there are two principles you need to know now: 1. the translation of large physical addresses from virtual addresses is taken over by the operating system and transparent to programmers. 2. the address space of the physical memory can be smaller than the address space of the virtual memory. The content of the virtual memory is not necessarily in the physical memory, and the physical address mapped to the virtual address is variable, this time, we will go somewhere else next time. The emergence of MDL breaks the above two principles. When you use MDL to bind a certain address segment. the translation of a virtual address to the address in the house becomes opaque to the programmer. the content in this virtual memory will definitely be in the physical memory (that is, the page will not be out), and the location will not change.

MDL can only be used in the kernel state, but the virtual memory it specifies can be either the kernel state address or the user State address. If it is a user-mode address, you must find out the context of the process where the address is located, because different processes have different address spaces, even if the address values are identical, the data contained in them must be completely different. If it is a kernel-state address, things will be a little simpler, because the kernel-state address space is shared, and the data contained in the same address must be the same.

The structure of MDL itself is written in DDK, but it belongs to the undocument structure. That is to say, if Microsoft wants to change it, it does not need to be notified in advance, so you 'd better not make any assumptions about it. However, it is okay to take a look, and you will not be pregnant. The following is the definition of the MDL data structure:

// An MDL describes pages in a virtual buffer in terms

// Of physical pages. The pages associated with

// Buffer are described in an array that is allocated

// Just after the MDL header structure itself.

//

// One simply calculates the base of the array

// Adding one to the base MDL pointer:

//

// Pages = (ppfn_number) (MDL + 1 );

//

// Notice that while in the context of the subject

// Thread, the base virtual address of a buffer mapped

// By an MDL may be referenced using the following:

//

// MDL-> startva | MDL-> byteoffset

//

Typedef struct _ MDL {

Struct _ MDL * next;

Cshort size;

Cshort mdlflags;

Struct _ eprocess * process;

Pvoid mappedsystemva;

Pvoid startva;

Ulong bytecount;

Ulong byteoffset;

} MDL, * pmdl;

From the annotations, we can see that MDL is actually a variable-length data structure. After this structure, it will be followed by an array to record the addresses mapped to the physical memory. The virtual address information is recorded in startva, and bytecount represents its size, and byteoffset represents its offset on the page. To obtain the correct VM address, you must use a method similar to MDL-> startva | MDL-> byteoffset. Before using MDL, you must apply for an MDL data structure. As mentioned above, MDL is a variable-length structure. You cannot simply apply for a struct _ MDL. You need to calculate the size of the array followed by and the values of each field in it, considering a series of annoying things such as page alignment, I suggest you do not manually create struct _ MDL, but use ioallocatemdl function to help you do these things. The ioallocatemdl function is defined as follows:

Pmdl

Ioallocatemdl (

In pvoid virtualaddress,

In ulong length,

In Boolean secondarybuffer,

In Boolean chargequota,

In out pirp optional

);

The first parameter is the virtual memory address, the second parameter is the virtual memory size, and the third parameter is used with the last parameter. If you specify an IRP when calling ioallocatemdl and secondarybuffer is true, then, this function automatically attaches the newly generated MDL to the end of the irp mdl list, if IRP is specified and secondarybuffer is false, this function sets IRP-> mdladdress to the newly generated MDL. changequota is generally false, only top-level drivers that generate a new IRP and pass it down will set it to true.

It is worth noting that the ioallocatemdl function, just like its name, is only responsible for allocating the memory required by the data structure. It is not responsible for truly binding the virtual memory and physical memory together, another batch of functions will be responsible for subsequent work, such as checking the permissions and locking the physical memory to prevent others from occupying the resources. This is done by the matrix functions. The function is defined as follows:

Void

MMP robeandlockpages (

_ Inout pmdl memorydescriptorlist,

_ In kprocessor_mode accessmode,

_ In lock_operation operation

);

The first parameter is the generated MDL, the second parameter specifies whether the user-state virtual storage or kernel-state virtual storage, and the third parameter specifies the access permission, which includes ioreadaccess, iowriteaccess, and iomodifyaccess (in fact, iowriteaccess and iomodifyaccess are exactly the same ...).

A clever employee has discovered a problem: the so-called detection permission must have a success or failure. How can this function not return any error codes, are these accessmode parameters installed? The answer is that when the permission match fails, the Matrix Function throws an exception. You must use the seh keyword such as _ Try _ blocks t to pack it. Here I have to vomit again: Have you really designed it? Considering the document quality of msdn, coupled with these amazing API designs, I suspect that these pile of things are simply patched up later, and the project deadline must be the day before the National Day holiday.

This is generally the case. You have obtained a physical memory that will never be page-out and will always correspond to the specified virtual memory. Good job! I wish you a happy time. If you have many sex issues that cannot meet your needs (sorry, I shouldn't say so, because the demand is always changeable), there is a function below to give you something new: the mmmaplockedpagesspecifycache function allows you to generate a new virtual address space from the specified MDL. Assume that your MDL is produced in a process context, but it is mainly used in other processes or where there is no process context (such as DPC and kernel thread), this function will be very useful, because after a process is switched or there is no process at all, the content of the same virtual address is different.

The mmmaplockedpagesspecifycache function is defined as follows:

Pvoid

Mmmaplockedpagesspecifycache (

_ In pmdl memorydescriptorlist,

_ In kprocessor_mode accessmode,

_ In memory_caching_type cachetype,

_ In_opt pvoid requestedaddress,

_ In ulong bugcheckonfailure,

_ In mm_page_priority priority

);

As you can see, the returned value is of the pvoid type, that is, the new virtual address. If you specify requestedaddress, the returned value should be the same as this parameter. Of course, the system may not be able to meet your specified address. In this case, if the bugcheckonfailure parameter is true, then the system will immediately bsod. Accessmode can be specified as kernelmode or usermode. If it is usermode, this function maps MDL to the user-state address space, and the user-State program can even directly read data in the kernel state.

The above is the general content related to MDL. I intentionally ignored most of the content related to virtual memory management (either directly not talking about it or being vague, as you can see ...), as mentioned above, we will talk about this part next time.