> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Sameer Ahuja
> Sent: 15 November 2006 12:10
> To: Tim Deegan; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: sameer.ahuja81@xxxxxxxxx
> Subject: 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)?
Not much, except that x86_64 has a greater number of page-table levels,
but everything else is identical.
>
> 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)
Not really - the major part of page-table management is exactly the
same, it's only where and how you get the catch or intercept for
page-faults that differs, but the management of the shadow pages is
still based on marking the actual page table entries that the guest has
read-only, and maintaining a "behind the scenes" copy (shadow)
page-table that actually reflect the REAL memory layout.
The difference is that the VT (and AMD's AMD-V/SVM) technology allows
the VMM to intercept the page-fault before it hits the interrupt
descriptor table (IDT), and thus it's independent of the implementation
of the guest-OS. In the para-virtual case, Xen handles the IDT, and
catches the page-fault via the exception vector.
Likewise, para-virtual Xen uses a "ring compression" method to catch
reads/writes involving CR3, so that Xen can track the value of CR3 and
maintain a "hidden" value of CR3 for the processor to use, that is
different from what the guest-OS thinks CR3 is. (The guest-OS will
attempt set CR3 to some value, but the intercept code in Xen will set
the ACTUAL CR3 register to point to the shadow page-table, rather than
the page-table maintained by the guest-OS). In HVM (VT/AMD-V), the CR3
intercept is handled by the virtualization technology and the relevant
bits in virtual machine control structurure/block, so there's no need to
modify the guest-OS. But the actual process needed to be done when the
CR3 is written with a new value is still the same.
In the future, AMD and Intel will introduce extensions that allow a
"second page-table", aka "Nested page tables", which essenitally allows
the processor to automatically translate a page-table entry "twice" by
having one set of page-tables for the guest-OS, and a second set of
page-tables for the hypervisor. This way, we can simply tell the
geust-OS that it's got memory from 0..256MB, and just remap that in the
HV to some other place(s) in the memory without the guest even knowing
that this is happening.
>
> 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.
You should be able to see how page-tables are dealt with in the em64t
documentation from Intel, or in the AMD64 Architecture Programmer's
Manual, Volume 2, chapter 5.
In case of how to handle shadow paging, there's little difference
between 2-level, 3-level (PAE) and 4-level page-tables, except for the
number of times you need to do something and the slight differences
between which bits can and can't be set at any particular level of
page-table.
Shadow page-table management is of course complicated and non-trivial,
but the idea behind it is independent of the number of levels used.
--
Mats
>
> 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
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home