[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: ????: [Xen-devel] shadow_clean_dirty_bitmap's another solution
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |