Hi, it's not an entirely trivial matter you're brining up here...
VirtualBox support two different ways of translating guest physical address to host physical addresses: 1. shadow page tables, and 2. nested page tables. The 2nd way relies on VT-x and AMD-V features and are much less complicated. The 1st is what we have to use for traditional software virtualization (the code path you located) and for hardware that does not support nested page tables. In the nested page table case (2), we construct a page table like mapping of guest physical addresses to host physical addresses as the guest accesses its physical pages. The first time a page is accessed we will allocate it. In the shadow page table case (1), we construct a shadow of the guest page tables with the guest physical addresses replaced by the actual host physical addresses. The current approach will create these tables lazily when the guest accesses them, i.e. on #PFs. Just like above, the first time a page is accessed (or shadowed thru a mapping), we will allocate it. The code responsible for creating and maintaing the shadow page tables is complicated because there are 3 basic paging modes (32-bit legacy, PAE and AMD64) and the guest and host might use different ones (host=PAE, guest=32-bit legacy). Too answer your question: CR3 holds the root address of the guest page table hierarchy and is therefore fundamental when constructing shadow page tables. When a #PF is raised because the guest accesses some address without a shadow page table entry, we have to walk the guest page hierarchy from CR3 and down to the guest entry to figure out whether (a) it's a valid access, (b) the physical address, and (c) the effective access mask of the page. Hope this helps a bit.. On Jun 7, 2011, at 4:39 AM, Francesco Di Paolo wrote: > hello, > i’m trying to understand how paging works on VirtualBox. So far, and in a > general way, i’ve understand that(and correct me if i’m wrong)when the guest > OS tries to allocate a page, a #PF is generated and this is handled by > trpmtrap0ehandler() in TRPM.cpp that relies on pgmtrap0ehandler(). This > function gives the control to the hypervisor that uses functions in the MM > and PGM group in order to allocate the page. Now i dont’ want anyone to > explain me the all process(i wish...but no). I’m looking for advices in order > to better understand the second part(what the hypervisor does)such as:could > it be useful to see the content of the CR3 register and why? > What i need are the right questions i have to ask to myself. > Any kind of help will be more than appreciated. > Thank you > > _______________________________________________ > vbox-dev mailing list > [email protected] > http://vbox.innotek.de/mailman/listinfo/vbox-dev -- Kind regards / Mit freundlichen Gruessen / Vennlig hilsen, bird -- ORACLE Deutschland B.V. & Co. KG Knut St. Osmundsen Werkstrasse 24 Senior Staff Engineer, VirtualBox 71384 Weinstadt, Germany mailto:[email protected] Hauptverwaltung: Riesstr. 25, D-80992 Muenchen Registergericht: Amtsgericht Muenchen, HRA 95603 Komplementaerin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschaeftsfuehrer: J. Kunz, M. van de Molen, A. van der Ven
_______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
