How does the Windows mode driver work, access to paged memory?

Question

1) The usermode process has its own "address context" that maps user-mode virtual addresses to a unique collection of physical pages. That is, the value of any particular virtual address changes from one moment to another, as the Windows XP Scheduler switches threads.

Part of the work of "switching threads" is to modify the page tables to refer to the context of the inbound process.

_

2) The driver in Windows kernel mode runs in an "arbitrary thread context".

A driver can create a system thread and work in its context ... but I'm talking about a situation where a system thread is not created.

The driver can use "ExAllocatePoolWithTag" to allocate paged pages (memory in volatile storage).

_

3) So, how does a driver access paged memory without any context ?

As can be seen from paragraph 1, access to paged memory is through tables of pages that are "Contextual".

when the driver starts in the context of other threads ... i.e. Page table entries point to the corresponding phy threads. mem, how then can a driver access their paged memory?

PS: me noob when programming the kernel. Do not get angry.

Answer 1

The concept used is the separation of the user / kernel address space. Each process address space is divided into a lower part (usually 2 GB), which is available for the process in user mode and is different for each process, and the upper part (remaining address space), available only in kernel mode, is the same for each process .

When the driver allocates paged memory, it is allocated on the kernel side of the broken address space, so it will be displayed in the kernel code no matter which pages of the process pages are loading at that time (since this part of the address space is displayed in the same way for each process).

Answer 2

The main thing to note is that all threads have the same kernel memory mapping. Thus, context switches between threads have (almost) no effect on the top 2 GB of virtual memory.