对于初识2中提出的问题，先来看下内核内存分布
kd> dd MmSessionPoolSize l1
80c394b4 00400000
kd> dd MiSessionPoolStart l1
80c394cc bc000000
kd> dd MiSessionViewStart l1
80c394c0 bc400000
现在还看下那个全局变量MmSessionSpace
kd> dd mmsessionspace l1
80c394e8 bf7f0000
kd> !address bf7f0000
bc400000 - 03400000
Usage KernelSpaceUsageSessionView
按windbg这里的计算，bc400000刚好为MiSessionPoolStart+MmSessionPoolSize,同时也是MiSessionViewStart 变量的值，配合上图，说明windbg把sessionpool结束位置到[会话映射文件内存区开始]之间这块区域都划为KernelSpaceUsageSessionView.
kd> ?bc400000 +03400000
Evaluate expression: -1082130432 = bf800000 刚好为 win32k的起始地址。所以KernelSpaceUsageSessionView往后的高地址就是为session image空间，MiSessionImageStart变量也说明了这一点
kd> dd nt!MiSessionImageStart l1
80c394b0 bf800000
kd> lm
start end module name
bf800000 bfa9a000 win32k (deferred)
通过上面，我们可以看到MmSessionSpace=bf7f0000，刚好在bf800000也就是session image内存区开始的前面一点点。
关于上面的计算，wrk的MmInitSystem（）函数中是有的，
例如
MmSessionSpace = (PMM_SESSION_SPACE)((ULONG_PTR)MmSessionBase + MmSessionSize - MmSessionImageSize - MI_SESSION_SPACE_STRUCT_SIZE);
这个计算就刚好是session image的start再往低空间-MI_SESSION_SPACE_STRUCT_SIZE个字节（MI_SESSION_SPACE_STRUCT_SIZE是0X10000）
回到初识2提到的问题，最后windbg调试得出了结论：
kd> dd MmSessionSpace l1
80c394e8 bf7f0000
在不同的session进程上下文中
bf7f0000映射的物理页不同。但这是如何做到的呢？这里应该是在trap0e里面实现的，但又有一个问题，bf7f0000内存块不可能在你想要的时候就会page out然后触发trap0e吧？
也许是在切换进程的时候，如果是不同的session就page out，又或者？？暂未找到，待续。。。
PS：由于Session空间的内存有这个特殊的机制，我想这就是为什么驱动在没有session的进程上下文里面（如system进程）不能访问win32k.sys的原因。
做shadow sdt hook的人就知道。
勒个去，上面问题的切换实现其实就是和进程切换时，切换CR3那样实现的。妈的，都失忆了。
之前记忆模糊，没细想即使是ring 3空间,不同进程相同的va,它们的pde和pte的地址其实是一样的，只是它们的内容都不同。这个其实就是和session space一模一样。
差点把基础丢了，这是今天凭空推想出pde和pte的地址应该一样，后来机器上细看，果真一样。
另外，书上也说了session space和system view空间这2块内核空间内存比较特殊，并不是在系统初始化的时候就初始化好的。之前看书没留意这块。