[Xen-devel] Re: [Queries] Unpinning and Unhooking shadow

[Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>]

At 21:12 +0530 on 14 Mar (1173906759), jeet wrote:
> 1. we do back traversing of per domain list of top level shadow pages and try 
> to unpin them using function call sh_unpin()
> 
> but in unpinning shadow we are unsetting pin bit in page->count_info and 
> decrement the reference count of shadow page
> using call to sh_put_ref() [define in xen/arch/x86/mm/shadow/private.h]
> 
> but in this function I am not able to understand why this condition is 
> unlikely? 
> 
> if ( unlikely(nx == 0) ) 
>         sh_destroy_shadow(v, smfn);

Because sh_put_ref is called in lots of other places too...

> as we are trying to make space for new shadow which would be created using 
> shadow_alloc() 
> so this sh_destroy_shadow must be called for any one of the entry in toplevel 
> list to free space of at least required order 
> and put back the pages in freelist of shadow pool ?

I don't understand your question.

When we need to free up some shadow memory, we walk the list of pinned
shadows and unpin them.  We walk them in reverse order because we hope
that less useful shadows will be at the end.  

When we unpin a shadow, if it's not in use right now, its refcount falls
to zero, which causes the whole tree of shadows below it to be
recursively destroyed. 

If that doesn't free up enough memeory, we try the next one.

> 3. Also after this if still space is not free then we try to unhooking the 
> same toplevel list  by going though each entry in list and 
> marking corresponding PML4 table's entries as 0 if that entry was marked 
> PRESENT.
> 
> But I am not able to understand how this will return pages back to per domain 
> freelist of shadow pages?

Because it will drop the refcount on all the lower-level shadows that
were being pointed to by those entries, which will cause some of them to
be destroyed.

When we have completed both scans of the pinned-shadows list, the only
shadows still allocated will be the top-level shadows for each vcpu in
the guest, and they will have no lower-level shadows attached to them.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
Registered office c/o EC2Y 5EB, UK; company number 05334508

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