[vbox-dev] Paging in VirtualBox

Tue Jun 7 09:57:33 GMT 2011

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
> vbox-dev at virtualbox.org
> 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:bird at sun.com

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20110607/0f78164f/attachment.html>