WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: ????: [Xen-devel] shadow_clean_dirty_bitmap's another solution

To: zhujun <zhujun@xxxxxxxxxxxxxx>
Subject: Re: ????: [Xen-devel] shadow_clean_dirty_bitmap's another solution
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Wed, 24 Jun 2009 11:10:56 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 24 Jun 2009 03:11:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <004e01c9f4af$af42bb10$0dc83130$@pku.edu.cn>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <004601c9f4ab$5ce9f030$16bdd090$@pku.edu.cn> <20090624091618.GO16056@xxxxxxxxxxxxxxxxxxxxx> <004e01c9f4af$af42bb10$0dc83130$@pku.edu.cn>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.17 (2007-11-01)
At 10:39 +0100 on 24 Jun (1245839974), zhujun wrote:
> Thanks for your advice.
> I am sorry my code was not complete in last mail. I forgot to mention that I
> was looking in sl2es because I wanted to only walk all the in-use L1 shadow
> page tables. Those not in-use L1 shadow page tables are not walked. That's
> because when a L1 shadow page table is selected to be in-use, the entries
> will be propagated from the guest page table again.

I'm afraid not.  The shadows are kept around and re-used.
Re-propagating the whole pagetables whenever CR3 is changed would be
very expensive.  So if the shadow already has the R/W bit set it will
keep being used without any more pagefaults, and the log-dirty bitmap
won't get updated on the next write. 

> Then, the R/W bit will
> be cleared because of log dirty mode. Just as shadow_blow_tables, it only
> blows the in-use shadow page tables. Others in the hash table are not blew
> down. Am I right?

No; shadow_blow_tables discards _all_ shadows, except the currently
in-use top-level pagetables, which it empties.  

Cheers,

Tim.

> Yes, my code is too cautious, because I have tried too many times to remove
> my faults. Unfortunately, I am not sure about my solution.
> 
> 
> -----????????-----
> ??????: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx] 
> ????????: 2009??6??24?? 17:16
> ??????: zhujun
> ????: xen-devel@xxxxxxxxxxxxxxxxxxx
> ????: Re: [Xen-devel] shadow_clean_dirty_bitmap's another solution
> 
> At 10:08 +0100 on 24 Jun (1245838118), zhujun wrote:
> > Hi,
> >          When doing live migration, the shadow code is translated to log
> dirty mode. However, in the shadow_clean_dirty_bitmap function, all the
> in-use shadow page tables are blew down. I think it is too crude, just as
> the comment of the function says. I am trying to find a better solution, but
> it does not succeeds. Would you please help me check my source code and give
> me some suggestions? My current solution is walking all the in-use L1 shadow
> page tables and clearing each L1 entry?s R/W bit if it has set.
> >          I don?t know whether it is enough to remove these R/W bits for
> live migration. If not, how to make all the pages of a PV domain read-only
> again? Thanks very much!
> >          My source code is here.
> > 
> >                     sl1mfn = shadow_l2e_get_mfn(*sl2e);
> 
> Stop right there! :)  Why are you looking in sl2es?  You need to make _all_
> the sl1es read-only for this to work.  You should be using
> hash_foreach() to walk through every l1 shadow.  Have a look at
> sh_remove_all_mappings for an example of code that walks every sl1 table.
> 
> Also your code below seems a bit too cautious: it should be OK to just check
> for_PAGE_PRESENT and _PAGE_RW and then clean _PAGE_RW.
> 
> Cheers,
> 
> Tim.
> 
> >                 if ( mfn_valid(sl1mfn) )
> >                 {
> >                    SHADOW_FOREACH_L1E(sl1mfn, sl1e, 0, 0, {
> >                         flags = shadow_l1e_get_flags(*sl1e);
> >                         target_mfn = shadow_l1e_get_mfn(*sl1e);
> >                         if(mfn_valid(target_mfn))
> >                         {
> >                                 pg = mfn_to_page(target_mfn);
> >                                 if ((pg != NULL) ||
> ((pg->u.inuse.type_info & PGT_type_mask) == PGT_writable_page))
> >                                 {
> >                                         if ((flags & _PAGE_PRESENT) &&
> (flags & _PAGE_RW))
> >                                         {
> >                                                 shadow_l1e_t ro_sl1e =
> shadow_l1e_remove_flags(*sl1e, _PAGE_RW);
> >                                                 (void) shadow_set_l1e(v,
> sl1e, ro_sl1e, sl1mfn);
> >                                         }
> >                                 }
> >                         }
> >                    });
> >                 }
> > 
> > 
> > zhujun
> > 
> 
> Content-Description: ATT00001.txt
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 
> 
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, Citrix Systems (R&D) Ltd.
> [Company #02300071, SL9 0DZ, UK.]
> 

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>