1) A usermode process has its own "address context", which maps the user-mode virtual addresses to a unique collection of physical page frames. That is, the meaning of any particular virtual address changes from one moment to the next as the Windows XP scheduler switches threads.
Part of work of "switching threads" is to change the page tables so that they refer to the incoming thread’s process context.
_
2) A Windows Kernel-mode Driver executes in "arbitrary thread context".
A driver may create a system thread and work in its context...but I am talking about the situation when one doesn't creates a system thread.
Driver can use "ExAllocatePoolWithTag" to allocate paged(memory in volatile storage).
_
3)So how does the driver access the paged memory without any context?
As seen in point 1, paged mem is accessed through page tables which are "Context specific".
when driver runs in some other threads context...i.e. page table entries points to the threads relevant phy. mem, how then can the driver get access to his paged memory?
PS: me noob at kernel programming. Don't get mad.
The concept used is the "user/kernel address space split". Each process address space is split into a lower portion (typically 2 GB) that is accessible to the process in user mode and differs for each process, and an upper portion (the remaining address space) that is only accessible in kernel mode, and is the same for every process.
When the driver allocates paged memory, it is allocated on the kernel side of the address space split, so it will be visible to kernel code no matter which processes page tables are loaded at the time (since this part of the address space is mapped in the same way for every process).
The main point to notice is that all threads have the same kernel memory mapping. So context switches between threads doesn't have (almost) any effect on the top 2GB of virtual memory.
来源：https://stackoverflow.com/questions/3396888/how-does-a-windows-kernel-mode-driver-access-paged-memory