pagetable pinning question

pagetable pinning question

[Christian Limpach]

Hi!

I want to use pinning for the L1/L2 pagetables.  The currently activated
pagetable maps itself and that works great.  But I (or rather whoever wrote
the pagetable code) also wants to map inactive pagetables and this doesn't
work because of the following check in get_twisted_l2_table:
    if ( (l2v >> PAGE_SHIFT) != entry_pfn )
    {
        MEM_LOG("L2 tables may not map _other_ L2 tables!\n");

Are there counting or protection issues why this is disallowed or was it
just not needed for Linux/Windows?

I guess a work around would be to switch to the inactive pagetable and
switch back when the mapping is no longer needed...

    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

Re: pagetable pinning question

[Ian Pratt]

> I want to use pinning for the L1/L2 pagetables.  The currently activated
> pagetable maps itself and that works great.  But I (or rather whoever wrote
> the pagetable code) also wants to map inactive pagetables and this doesn't
> work because of the following check in get_twisted_l2_table:
>     if ( (l2v >> PAGE_SHIFT) != entry_pfn )
>     {
>         MEM_LOG("L2 tables may not map _other_ L2 tables!\n");
> 
> Are there counting or protection issues why this is disallowed or was it
> just not needed for Linux/Windows?

Interesting. I guess as well as having a linear mapping [*] of
it's current page table, NetBSD reserves a page directory slot
for creating temporary linear mappings of other page tables it
wants to manipulate (e.g. during fork etc).

Like anything to do with linear mappings, figuring this out is
going to require a damp towel wrapped around one's head...

If the other L2 is pinned, I think its safe to allow. However, if
it's not things are going to get ugly (and slow).

> I guess a work around would be to switch to the inactive pagetable and
> switch back when the mapping is no longer needed...

I suspect it wants both linear mappings in place at the same
time, e.g. for doing a PTE copy.

Can you ensure the other L2 is pinned?

Cheers,
Ian


[*] i.e. it uses a page directory entry to point back to the page
containing the directory. The net result is you end up with a 4MB
VA region that containing a linear mapping of all your PTEs,
which makes manipulating them very easy. Linux does not use
linear mappings at all, but XP does.


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

Re: pagetable pinning question

[Christian Limpach]

> Interesting. I guess as well as having a linear mapping [*] of
> it's current page table, NetBSD reserves a page directory slot
> for creating temporary linear mappings of other page tables it
> wants to manipulate (e.g. during fork etc).

yes, there is a function which returns the VA where the requested page table
is linearly mapped.  For the kernel's page table and for the current page,
this always returns the current page table's linear mapping VAFor any other
page table, the alternate page directory linear mapping slot is changed and
the VA of the corresponding memory is returned.

> Like anything to do with linear mappings, figuring this out is
> going to require a damp towel wrapped around one's head...

oh yes...

> If the other L2 is pinned, I think its safe to allow. However, if
> it's not things are going to get ugly (and slow).

It is, I'm pinning the L2 tables right after they are created.  All page
directories are pinned all the time and I'm now always using mmu_update to
make changes.  I've removed the check in my Xen and so far this works quite
well...

> > I guess a work around would be to switch to the inactive pagetable and
> > switch back when the mapping is no longer needed...
>
> I suspect it wants both linear mappings in place at the same
> time, e.g. for doing a PTE copy.

As far as I can tell we only need access to one linear mapping at a time.  I
suspect the motivation for having the alternate mapping is avoiding the
switch of the table and keeping the code simple (no special treatment for
inactive page tables).

     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

Re: pagetable pinning question

[Keir Fraser]

> I want to use pinning for the L1/L2 pagetables.  The currently activated
> pagetable maps itself and that works great.  But I (or rather whoever wrote
> the pagetable code) also wants to map inactive pagetables and this doesn't
> work because of the following check in get_twisted_l2_table:
>     if ( (l2v >> PAGE_SHIFT) != entry_pfn )
>     {
>         MEM_LOG("L2 tables may not map _other_ L2 tables!\n");
> 
> Are there counting or protection issues why this is disallowed or was it
> just not needed for Linux/Windows?

Both. 

Linux doesn't use linear pagetables, and Windows only has each page
directory mapping itself. 

Also, reference counting is somehat more complicated -- currently we
only track one mutually-exclusive type per page frame (writeable, page
directory, page table, or segment-descriptor table). If we allow page
directories to map other page directories then we really want to track
the "uses as page directory" and "uses as page table" separately.

Consider a page directory D mapped as a linear pagetable into every
other page directory in the system. If D is freed and subsequently
reused as a page table, we won't change Xen's 'type field' for D until
all mappings of D in other page tables have been blown away.

I see two possibilities:
 1. Whenever a PD is freed, require the guest to expunge all mappings
 of the PD from other page directories. Otherwise subsequent attempts
 to use the PD as a pagetable will fail.
 2. Reference count "used as PD" and "used as PT" separately. These
 counts could be maintained in the same memory word since the former
 count is always going to be very small.

Case 1 can easily be implemented -- would it be a reasonable fit with
NetBSD's operation when a page directory is released?
 
> I guess a work around would be to switch to the inactive pagetable and
> switch back when the mapping is no longer needed...

I guess it depends how often a process accesses another's PTEs. Maybe
fork times and CoW-fault latencies might be slowed down if you took
this approach? 

I can remove the check in Xen and requrie the guest to be involved in
cleaning up when a page directory is released, if this is a suitable
approach for NetBSD.

 -- Keir


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

Re: pagetable pinning question

[Keir Fraser]

>  1. Whenever a PD is freed, require the guest to expunge all mappings
>  of the PD from other page directories. Otherwise subsequent attempts
>  to use the PD as a pagetable will fail.

I should clarify that I mean "attempts to use the PD as a _normal_
pagetable will fail". 

Uses as a linear pagetable and uses as a normal pagetable are
different. In the former case we require the mapping to be
read-only. In the latter it is permitted to be read-write. 

So NetBSD would reallocate PD for use as a normal PT and would attempt
to introduce a read-write mapping of the page frame. Unless all linear
mappings of PD have been expunged then this would fail because Xen
thinks that the type is still "page directory". 

 -- Keir


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

Re: pagetable pinning question

[Bin Ren]

Hi,

I'm a bit confused by parts of the discussion going here. Can anyone
explain the difference between linear page table and normal page table?
Linux page tables are all linear, i.e. contiguous page table entries
correspond to contiguous virtual pages. Is this right? How about
NetBSD?

How can one page directory be mapped from another page directory?

My understanding is: (maybe wrong) each process has only one
page directory and 1024 page tables. Each page directory and page
table fits into one page (on 32-bit computers with 4k page size).
Not all page tables are allocated physical page frames initially. During
a context switch from process A to process B, A's PD and PTs can be
swapped out (in face of memory shortage), releasing physical page
frames for use by B. So, how can one PD be mapped by another PD?

What am I missing here?

Thanks,
Bin



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

Re: pagetable pinning question

[Zachary Amsden]

This is a good question, as all this terminology suffers from potential 
overloading of the word "linear".  The linear recursive map works as 
follows:

Register %cr3 contains a physical page frame which points to the current 
PDP.  This physical page contains the physical frame addresses of all 
the second level page tables.  One of these entries is special... it 
contains the physical frame address of the PDP itself.  The index of 
this entry now corresponds to the high 10 bits of a virtual memory 
address.  Accesses to this 4Mb region of virtual memory are translated 
through the PDP, which points to the actual (likely non-contiguous) 
physical page tables.  So you have effectively mapped the non-contiguous 
PTEs into the 4Mb contiguous (i.e. linear) virtual memory region 
corresponding to the PDP index.  This greatly simplifies some 
operations, since you can use the hardware to map the page tables and 
access them as a giant array.  This is the linear map.

The map is actually recursive, since the PDP itself will be mapped into 
the same VM region.  So if your special index was say 767 (as in 
NetBSD), then the 4Mb VM region at 0xbfc00000 would contain a linear 
mapping of your page tables.  The page at 0xbfeff000 would contain the 
PDP itself, and the virtual address 0xbfeffbfc would contain the 
physical address of the PDP.

You can also use other slots in the PDP to map other processes page 
tables, which might be useful for shared memory access or implementing 
fork().  This is what causes the problems with reference accounting, 
since you have the same page being used both as a PDP and a PTP, with 
possible circular references.

Zachary Amsden
zamsden@cisco.com

Bin Ren wrote:

> Hi,
>
> I'm a bit confused by parts of the discussion going here. Can anyone
> explain the difference between linear page table and normal page table?
> Linux page tables are all linear, i.e. contiguous page table entries
> correspond to contiguous virtual pages. Is this right? How about
> NetBSD?
>
> How can one page directory be mapped from another page directory?
>
> My understanding is: (maybe wrong) each process has only one
> page directory and 1024 page tables. Each page directory and page
> table fits into one page (on 32-bit computers with 4k page size).
> Not all page tables are allocated physical page frames initially. During
> a context switch from process A to process B, A's PD and PTs can be
> swapped out (in face of memory shortage), releasing physical page
> frames for use by B. So, how can one PD be mapped by another PD?
>
> What am I missing here?
>
> Thanks,
> Bin
>
>
>
> -------------------------------------------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel




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

Re: pagetable pinning question

[Bin Ren]

Hi, Zachary:

I can't describe how grateful I'm for your detailed, clear and 
professional answer!
Definitely a high-ranking in FAQ!!

Thanks so much!
-- Bin

On 6 Feb 2004, at 01:28, Zachary Amsden wrote:

> This is a good question, as all this terminology suffers from 
> potential overloading of the word "linear".  The linear recursive map 
> works as follows:
>
> Register %cr3 contains a physical page frame which points to the 
> current PDP.  This physical page contains the physical frame addresses 
> of all the second level page tables.  One of these entries is 
> special... it contains the physical frame address of the PDP itself.  
> The index of this entry now corresponds to the high 10 bits of a 
> virtual memory address.  Accesses to this 4Mb region of virtual memory 
> are translated through the PDP, which points to the actual (likely 
> non-contiguous) physical page tables.  So you have effectively mapped 
> the non-contiguous PTEs into the 4Mb contiguous (i.e. linear) virtual 
> memory region corresponding to the PDP index.  This greatly simplifies 
> some operations, since you can use the hardware to map the page tables 
> and access them as a giant array.  This is the linear map.
>
> The map is actually recursive, since the PDP itself will be mapped 
> into the same VM region.  So if your special index was say 767 (as in 
> NetBSD), then the 4Mb VM region at 0xbfc00000 would contain a linear 
> mapping of your page tables.  The page at 0xbfeff000 would contain the 
> PDP itself, and the virtual address 0xbfeffbfc would contain the 
> physical address of the PDP.
>
> You can also use other slots in the PDP to map other processes page 
> tables, which might be useful for shared memory access or implementing 
> fork().  This is what causes the problems with reference accounting, 
> since you have the same page being used both as a PDP and a PTP, with 
> possible circular references.
>
> Zachary Amsden
> zamsden@cisco.com
>
> Bin Ren wrote:
>
>> Hi,
>>
>> I'm a bit confused by parts of the discussion going here. Can anyone
>> explain the difference between linear page table and normal page 
>> table?
>> Linux page tables are all linear, i.e. contiguous page table entries
>> correspond to contiguous virtual pages. Is this right? How about
>> NetBSD?
>>
>> How can one page directory be mapped from another page directory?
>>
>> My understanding is: (maybe wrong) each process has only one
>> page directory and 1024 page tables. Each page directory and page
>> table fits into one page (on 32-bit computers with 4k page size).
>> Not all page tables are allocated physical page frames initially. 
>> During
>> a context switch from process A to process B, A's PD and PTs can be
>> swapped out (in face of memory shortage), releasing physical page
>> frames for use by B. So, how can one PD be mapped by another PD?
>>
>> What am I missing here?
>>
>> Thanks,
>> Bin
>>
>>
>>
>> -------------------------------------------------------
>> 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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/xen-devel
>
>
>
>
> -------------------------------------------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>



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

Re: pagetable pinning question

[Christian Limpach]

> Also, reference counting is somehat more complicated -- currently we
> only track one mutually-exclusive type per page frame (writeable, page
> directory, page table, or segment-descriptor table). If we allow page
> directories to map other page directories then we really want to track
> the "uses as page directory" and "uses as page table" separately.
>
> Consider a page directory D mapped as a linear pagetable into every
> other page directory in the system. If D is freed and subsequently
> reused as a page table, we won't change Xen's 'type field' for D until
> all mappings of D in other page tables have been blown away.
>
> I see two possibilities:
>  1. Whenever a PD is freed, require the guest to expunge all mappings
>  of the PD from other page directories. Otherwise subsequent attempts
>  to use the PD as a pagetable will fail.
>  2. Reference count "used as PD" and "used as PT" separately. These
>  counts could be maintained in the same memory word since the former
>  count is always going to be very small.
>
> Case 1 can easily be implemented -- would it be a reasonable fit with
> NetBSD's operation when a page directory is released?

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?

The alternate PD mapping are left lingering in case the same mapping is
requested again.  It would be possibly to always kill the alternate mapping
(which we do on MP) but it requires a tlbflush (I had inadvertedly commented
out the tlbflush and the results were quite mysterious ;-))

The destructor would then have to check all PDs to see if the to be
destroyed PD is mapped in any and clear the mapping.  That would be
reasonable since destruction happens only when the kernel's VA usage
requires additional PTs which causes the pool cache to be flushed or when
unused items from the pool are drained because of resource shortage.

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?

> > I guess a work around would be to switch to the inactive pagetable and
> > switch back when the mapping is no longer needed...
>
> I guess it depends how often a process accesses another's PTEs. Maybe
> fork times and CoW-fault latencies might be slowed down if you took
> this approach?

yes, it's preferable to use the alternate mapping if possible...

> I can remove the check in Xen and requrie the guest to be involved in
> cleaning up when a page directory is released, if this is a suitable
> approach for NetBSD.

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.

    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

Re: pagetable pinning question

[Keir Fraser]

> 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!). 
 
> The alternate PD mapping are left lingering in case the same mapping is
> requested again.  It would be possibly to always kill the alternate mapping
> (which we do on MP) but it requires a tlbflush (I had inadvertedly commented
> out the tlbflush and the results were quite mysterious ;-))
> 
> The destructor would then have to check all PDs to see if the to be
> destroyed PD is mapped in any and clear the mapping.  That would be
> reasonable since destruction happens only when the kernel's VA usage
> requires additional PTs which causes the pool cache to be flushed or when
> unused items from the pool are drained because of resource shortage.
> 
> 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 guess a work around would be to switch to the inactive pagetable and
> > > switch back when the mapping is no longer needed...
> >
> > I guess it depends how often a process accesses another's PTEs. Maybe
> > fork times and CoW-fault latencies might be slowed down if you took
> > this approach?
> 
> yes, it's preferable to use the alternate mapping if possible...
> 
> > I can remove the check in Xen and requrie the guest to be involved in
> > cleaning up when a page directory is released, if this is a suitable
> > approach for NetBSD.
> 
> 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.

 -- Keir


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

Re: pagetable pinning question

[Christian Limpach]

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

Re: pagetable pinning question

[Ian Pratt]

> 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 believe everyone is in agreement as regards how to add support
in 1.2.

The only problem is in 1.3, where pages can potentially be shared
between multiple domains. If one of the domains is destroyed, we
need to think through how to safely reclaim the memory.

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

With the proposed mod, this should work fine. (with the 1.3
memory reclamation caveat).

Ian


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

Re: pagetable pinning question

[Keir Fraser]

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

Okay, I've checked in a fix for 1.2 that bumps the reference ocutn
when mapping other PDs, and has an appropriate destructor/cleanup
function. 

I'm still thinking about the tidiest way to change 1.3 to get the same
behaviour. 

 -- Keir


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

Re: pagetable pinning question

[Keir Fraser]

> > 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.
> 
> Okay, I've checked in a fix for 1.2 that bumps the reference ocutn
> when mapping other PDs, and has an appropriate destructor/cleanup
> function. 
> 
> I'm still thinking about the tidiest way to change 1.3 to get the same
> behaviour. 

I think I have the right solution now. I've checked it into the
unstable tree.

 -- Keir


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