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
|
Home