From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Subject: Re: Page table and memory management Date: Thu, 3 Mar 2005 17:11:31 -0500 Message-ID: References: <2fcc2621218074768a944b7fce18ddf3@cl.cam.ac.uk> Reply-To: Richard Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In-Reply-To: Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Keir Fraser Cc: xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org Hi, I think the flow graph in the previous email was too big and might not display properly: do_mmu_update | | /---------------------------------\ | | | | \/ \/ mod_l2_entry do_extended_command | | | | \/ | get_page_from_l2e | | | | | \---------------------------------/ | | \/ get_page_and_type_from_pagenr | | \/ get_page_type Richard On Thu, 3 Mar 2005 17:00:17 -0500, Richard wrote: > Hi Keir, > > I am still having trouble to edit the page table entries with the > mmu_update hypercall. > I am actually updating the mini-os. The mem management in mini-os is > pretty outdated. For example, it assumes that the initial page tables > are placed at the top of available memory and hence does not count > properly the total amount of pages that have been allocated to the > domain. I am extending the initial PGD and PT given to mini-os at boot > time to map the available memory that I can use. > > I tried to first pin a level 1 page frame before inserting it as an > entry in the level 2 PGD. > Whether I pin a level1 page frame first or I start using it directly > as a page table, it does not matter the mmu_update hypercall still > fails. > > I traced through the XEN code, in the file arch/x86/memory.c. Whether > excuting a MMU_NORMAL_PT_UPDATE or a MMU_EXTENDED_COMMAND type of > command, the function do_mmu_update() eventually calls the helper > function get_page_and_type_from_pagenr() which in turns call the > function get_page_type(). Below I drew a call graph. > > do_mmu_update > | > | > > /------------------------------------------------------------------------------\ > | > | > \/ > \/ > mod_l2_entry > do_extended_command > | > | > \/ > | > get_page_from_l2e > | > | > | > | > | > > \------------------------------------------------------------------------------/ > | > \/ > get_page_and_type_from_pagenr > | > \/ > get_page_type > > The get_page_type() checks the upperbits of the 'typeinfo' field of > the page frame to make sure it is of type 'PGT_l1_page_table'. > get_page_type() also does another check to verify that the 'typeinfo' > field also contains the 10 upper bits of the virtual address that this > page frame is suppose to eventually map to. > > > Xen will automatically infer the type when you attach an L1 to an > > existing L2. Xen will infer the L2 type when the L2 gets used as > > current pagetable base. > So I do not see where XEN is automatically inferring the L1 type when > I am inserting for the 1st time the L1 page frame into the L2. In > order to use a page frame as an L1 page table, I have to find a way to > tell XEN to update the corresponding typeinfo field in order to pass > the verification in get_page_type(). > > Thanks > Richard > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click