| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] pagetable pinning question
> > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home