At 16:02 -0400 on 09 Jul (1183996971), Yongjun Jeon wrote:
> I noticed that the shadow pagetable code has went through some serious 
> design change since 3.0.2, and I couldn't find a good documentation that 
> explains how the old code maps to the new code.
>
> Can anyone please explain the exact nature of the change - how the new 
> functions replace the old ones?
The architecture of the shadow code changed considerably after 3.0.2; I
doubt you will have much luck porting that patchset directly.
The major change is that instead of "unhooking" shadow pages from the
hierarchy when a guest writes to a pagetable, and re-syncing the shadow
to the pagetable afterwards, we trap and emulate writes to pagetables, 
synchronously updating the shadows as we go. But also the way shadow
pagetables are allocated, tracked, protected and destroyed have
changed.
Most of the moving parts of the shadow code (including the shadow lock)
are now private to the arch/x86/mm/shadow directory. Outside callers
use the functions in asm-x86/paging.h, which dispatch to shadow code or
to hardware paging assistance as appropriate.
The p2m table is now organised as a pagetable, and managed by
arch/x86/mm/p2m.c I expect that most of the changes you will want to
make are in there; changes to the p2m map are reflected automatically in
the shadow pagetables by the callback to paging_write_p2m_entry().
For data pages, the function sh_get_page_from_l1e() handles reference
counting and will need to know about the extra domain ID used. For
pagetable pages, shadow_promote() still exists and would be a good place
to make sure the promoted page is not copy-on-write.
Tim.
-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel