From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?EUC-KR?B?udrAurq0?= Subject: page table pages with checkpoint functionality Date: Tue, 11 May 2010 21:04:17 +0900 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1720281328==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com, brendan@cs.ubc.ca List-Id: xen-devel@lists.xenproject.org --===============1720281328== Content-Type: multipart/alternative; boundary=00032556313221bb1504865053dd --00032556313221bb1504865053dd Content-Type: text/plain; charset=ISO-8859-1 Hi, all I am analyzing the xen source about checkpoint functionality (tools/libxc/xc_domain_save.c, xc_domain_restore.c) during saving page table pages to disk or another machine( in the case of live migration), those pages should be canonicalized, which means that references to actual mfns are replaced with references to the corresponding pfns I can understand that, but I could see the another point that I can't understand After printing out the page table entries, I found that most of page table entries has _PAGE_DIRTY, _PAGE_ACCESSED, _PAGE_RW bit. As soon as guest OS's booting is completed, I checkpointed the guest OS. (command is xm save [domainU]) L1 pagetable pages:341 L2 pagetable pages:71 L3 pagetable pages:19 L4 pagetable pages:0 (the number of L4 is 0 because of I have used PAE enabled xen) As futher investigating, L1 page table entries, page table entries that have _PAGE_DIRTY :131951 page table entries that have _PAGE_ACCESSED :133960 page table entries that have _PAGE_RW :129787 In PAE enabled level 3 paging, each L1 page table has 512 entries, so total entries 341*512 = 174592 70~80% ptes have those bits I make sense of many _PAGE_ACCESSED bits. but, why do those pages have another 2 bits?? Thanks. -- Eunbyung Park --00032556313221bb1504865053dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all

I am analyzing the xen source about checkpoint functionality= (tools/libxc/xc_domain_save.c, xc_domain_restore.c)

during saving p= age table pages to disk or another machine( in the case of live migration),= those pages should be canonicalized,
which means that references to actual mfns are replaced with references to = the corresponding pfns

I can understand that, but I could see the an= other point that I can't understand

After printing out the page = table entries, I found that most of page table entries has _PAGE_DIRTY, _PA= GE_ACCESSED, _PAGE_RW bit.

As soon as guest OS's booting is completed, I checkpointed the gues= t OS. (command is xm save [domainU])

L1 pagetable pages:341
L2 pa= getable pages:71
L3 pagetable pages:19
L4 pagetable pages:0
(the n= umber of L4 is 0 because of I have used PAE enabled xen)

As futher investigating, L1 page table entries,

page table entri= es that have _PAGE_DIRTY :131951
page table entries that have _PAGE_ACCE= SSED :133960
page table entries that have _PAGE_RW :129787

In PAE= enabled level 3 paging, each L1 page table has 512 entries, so total entri= es 341*512 =3D 174592
70~80% ptes have those bits

I make sense of many _PAGE_ACCESSED bits= .
but, why do those pages have another 2 bits??

Thanks.
-- Eunbyung Park
--00032556313221bb1504865053dd-- --===============1720281328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1720281328==--