Re: pagetable pinning question

[Christian Limpach <chris@pin.lu>]

> > I think it would.  In NetBSD PDs are managed in a cached pool, i.e. the
pool
> > items are initialized by the pool system and must be returned to the
pool in
> > an initialized/clean state.  I have the pool item constructor pin the
pages
> > and the destructor unpin the pages.  I would expect a problem when the
PD's
> > page is released from the pool (the page is unpinned) while it's still
> > mapped in another PD?  It won't fail but leave the page mapped as an L1
page
> > while it's untyped?
>
> That is correct (except it will remain pinned as an L2 table -- many
> people have told me that I have L1 and L2 the wrong way round!).

*think* *think*  I did really mean mapped as an L1 page:
PD1 is the current page directory, PD2 is another page directory which is
pinned (L2 type).  We enter PD2 as a pagetable in PD1, Xen handles this is a
twisted L2 entry and doesn't reference count PD2.  Now we unpin PD2 which
would drop its page's reference count to 0 while the page is still installed
in PD1 as a pagetable.

> > So, for case 1, would you then just increment the page's type count in
> > get_twisted_l2_table an decrement it in mod_l2_entry when put_l1_table
> > fails?
>
> Actually, it now occurs to me that this strategy has a nasty flaw (at
> least it does in the v1.3 page-management code). We can end up with
> circular references: e.g. PD A maps PD B, and vice versa. Unless code
> is added to detect such loops this will mess up page-frame
> reclamation since they hold each other as type 'L2'. :-(
>
> Hmmmm... I think a simple hack that allows these circular references
> is sufficient in 1.2 --- we don't properly do reference-count-based
> reclamation in Xen 1.2. Xen 1.3 is going to need some more thought --
> wet towel time :-)

I can't comment on the 1.3 problem but for 1.2 it would seem to me that
simply increasing the L2's reference count when we map a different L2 table
as a twisted L2 table would keep things sane even in the circular case, as
long as we unmap in the opposite order.  Or am I missing something?

I think I can guarantee that the unmap order is correct if I clear the
alternate mapping whenever I switch pagetables (and there's no switches
between a requested mapping and the corresponding unmap).  The pool cache
destructor would then also only need to check the current pagetable's
alternate mapping.

> > yes please, I think it is.  I have removed the check in my Xen but
without
> > the added ref counting and without the extra cleaning up in the
destructor.
>
> I expect your current hack can lead to reference-count inconsistencies
> within Xen. We need to sort this out as a priority. I'll fix for 1.2
> tomorrow and then think harder about the correct solution for 1.3.

I can't see how...  The alternate PD is pinned, so all changes to it will
use mod_l2_entry and all changes to the PT's it references will use
mod_l1_entry.  Why would the fact that it's mapped by another pagetable mess
up the ref couting?

     christian



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn