Re: [Xen-devel] Consult some concepts about shadow paging mechanism

[Jui-Hao Chiang <windtracekimo@xxxxxxxxx>]

Hi, sorry for disturbing you guys again.

Assume guest's paging level is 2 and shadow is using level 3 PAE.
I am now trying to dump the L2 shadow page table information in the
beginning of sh_update_cr3() as the following (actually copying the
code from sh_audit_l2_table and audit_gfn_to_mfn functions)

The code accidentally crashes in  guest_l2e_get_flags(*gl2e) of the
sh_walk_l2_table I wrote.
However, the weird part is the code doesn't crash in gfn =
guest_l2e_get_gfn(*gl2e) which is accessing the *gl2e in a similar way
as guest_l2e_get_flags.

static inline mfn_t
convert_gfn_to_mfn(struct vcpu *v, gfn_t gfn, mfn_t gmfn)
{
    p2m_type_t p2mt;
    if ( !shadow_mode_translate(v->domain) )
        return _mfn(gfn_x(gfn));

    if ( (mfn_to_page(gmfn)->u.inuse.type_info & PGT_type_mask)
         != PGT_writable_page )
        return _mfn(gfn_x(gfn)); // This is a paging-disabled shadow
    else
        return gfn_to_mfn(v->domain, gfn, &p2mt);
}

/* JuiHao: walk the l2 shadow page table based on input sl2mfn */
static int sh_walk_l2_table(struct vcpu *v, mfn_t sl2mfn, mfn_t x)
{
        guest_l2e_t *gl2e, *gp;
        shadow_l2e_t *sl2e;
        mfn_t sl1mfn, gl2mfn;
        gfn_t gfn;
        mfn_t gmfn;
        int done = 0;

        /* Follow the backpointer in struct shadow_page_info to get guest l2mfn 
*/
        gl2mfn = _mfn(mfn_to_shadow_page(sl2mfn)->backpointer);
        gl2e = gp = sh_map_domain_page(gl2mfn);

        SHADOW_FOREACH_L2E(sl2mfn, sl2e, &gl2e, done, v->domain, {

                gfn = guest_l2e_get_gfn(*gl2e);  // ###!!!! Works Fine !!!!!####
                sl1mfn = shadow_l2e_get_mfn(*sl2e);
                
                if (mfn_valid(sl1mfn) && (shadow_l2e_get_flags(*sl2e) & 
_PAGE_PRESENT)) {

                        // We get this gmfn is just to double check if this is 
equal to sl1mfn
                        gmfn = (guest_l2e_get_flags(*gl2e) & _PAGE_PSE) // 
###!!!! CRASH !!!!!####
                                ? get_fl1_shadow_status(v, gfn)
                                : get_shadow_status(v, convert_gfn_to_mfn(v, 
gfn, gl2mfn),
                                SH_type_l1_shadow);
                        
                        if (mfn_x(gmfn) != mfn_x(sl1mfn)) {
                                printk("!! gmfn %" PRI_mfn " != sl1mfn %" 
PRI_mfn "\n", gmfn, sl1mfn);
                        } else {
                                printk("going down to traverse level 1 SPT\n");
                        }
                }

        });
        sh_unmap_domain_page(gp);
        return 0;
}

Could you help a little bit on this?
Many thanks,
Jui-Hao

On Fri, Apr 24, 2009 at 9:32 AM, Gianluca Guida
<gianluca.guida@xxxxxxxxxxxxx> wrote:
> On Fri, Apr 24, 2009 at 6:23 AM, Jui-Hao Chiang <windtracekimo@xxxxxxxxx> 
> wrote:
>> I have some additional doubts as the following:
>> (1) For normal data page, in order to propagate the Dirty or Access
>> bit from SPTE to GPTE, the hypervisor needs to set Read-Only in the
>> SPTE. When the write page fault of this data page comes, hypervisor
>> can propagate the Dirty or Access bit to GPTE and set it to R/W. My
>> question is when does the hypervisor make it Read-Only again? Is there
>> any place inside the source code you can point out?
>
> What happens is this: the guest has to clear the dirty/accessed bit
> and then flush the tlb (or invlpg the entry).
> If the pagetable is mapped read only (as in levels > 1) the write to
> the pagetable will trigger the emulator that will update the entry.
> Otherwhise (if the page is out of sync, which means a writable guest
> pagetable, and this happens when it's an L1) the flushtlb will do the
> job of updating the shadow entry.
>
> Look at how sh_propagate function works and when it get called. It's
> what you're looking for.
>
>> (2) How many shadow pages are maintained for each guest domain? If the
>> hypervisor keep only one shadow page table for the active process in
>> each guest domain, then during the guest context-switch, it might
>> erase the entire shadow page table, and re-construct it for the new
>> process, which seems a lot of overhead. I have checked the
>> sh_update_cr3(), but not sure of the detailed mechanism.
>
> There's a pool of shadow memory that get reused in a pseudo-LRU
> manner. Across cr3 switch toplevel pagetables are kept in memory, and
> unshadowed when evicted by the allocator or when other things happens,
> mostly based on heuristic and reference counting.
>
> Thanks,
> Gianluca
>
> --
> It was a type of people I did not know, I found them very strange and
> they did not inspire confidence at all. Later I learned that I had been
> introduced to electronic engineers.
>                                                  E. W. Dijkstra
>

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