| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Need information related to shadowing
Thanks a lot Tim.
Your reply was useful but I have one more query - how this handling
related to shadow tables is different between IA 32(x86_32) and EM64T
(x86_64)?
The thing is that with EM64T Intel Virtualization Technology comes into
the picture and I think that it shifts a lot of responsibilities from
Xen to the H/W level. (This is what I have understood after going
through a couple of articles on Intel site and other sites)
I have not been able to find out this in the Xen code though I can
clearly see that the directories are different for x86_32 and x86_64.
Please send me any article or paper related to this.
Regards,
Sameer
-----Original Message-----
From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxxxxx]
Sent: Wednesday, November 15, 2006 3:44 PM
To: Sameer Ahuja
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Need information related to shadowing
At 09:41 +0530 on 15 Nov (1163583694), Sameer Ahuja wrote:
> Can you please tell me how is Shadow Page Table generated/maintained?
Shadow pagetables are generated in two places in the shadow code: on a
guest CR3 change a top-level shadow is generated (multi.c:
sh_update_cr3() calls sh_set_toplevel_shadow()), and all other shadows
are
generated in the page fault handler (sh_page_fault() calls
shadow_get_and_create_l1e(), which recursively builds the shadow
tables).
Shadow entries are filled in by the l*e_propagate_from_guest()
functions, which are called directly from the page fault handler and
when we see a write to a guest pagetable (via the
shadow_validate_guest_entry() and shadow_validate_guest_pt_write()
functions).
The control flow is a bit tricky there because we need to track shadows
of different paging modes at the same time: a single page can have up
to eight different shadows. To deal with different paging modes, the
file multi.c is compiled multiple times, and its functions renamed to
include the paging mode they handle. We can then call the correct
function by name (see the various dispatch tables in common.c), or call
the functions for the paging mode each vcpu is currently in, via the
v->arch.shadow.mode array of pointers.
Shadows are destroyed when their reference count hits zero, typically
because shadow memory is being reclaimed: shadow_prealloc() un-pins
top-level shadows which causes them to recursively destroy all their
children.
Cheers,
Tim.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home