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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > I think it would. In NetBSD PDs are managed in a cached pool, i.e. thepool> > items are initialized by the pool system and must be returned to thepool in> > an initialized/clean state. I have the pool item constructor pin thepages> > and the destructor unpin the pages. I would expect a problem when thePD''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 L1page> > 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 butwithout> > the added ref counting and without the extra cleaning up in thedestructor.> > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel