[vbox-dev] Managing CR3 on guest O.S

Francesco Di Paolo negroni_85 at hotmail.it
Mon Jul 25 10:03:46 GMT 2011





	
	
	
	

ok,i get
it. But, in order to maintain consistency between shadow PT and guest
PT, we have to write-protect the guest PT. The
hypervisor write-protects all physical pages that constitute the
guest PT. Any modification by the guest results in a page fault
exception. Now, when the guest O.S. change the CR3, we practically
have new PTs. What i would like to know is if VirtualBox uses the
memory tracing techinique to maintain that consistency(write
protect PTs →
force
trap into hypervisor on each update)or another method(i found only
few documents, the most of them talks about memory traces):Lazy
shadowing of virtual page table:identify synchronisation
points,possible due to TLB semantics,real PT updates only become
effective once loaded into TLB,
explicit
TLB loads and flushes are natural synchronisation points. Can anyone
help me pointing out wich method is used by VirtualBox???


From: knut.osmundsen at oracle.com
Date:
Sat, 23 Jul 2011 21:59:48 +0200
To:
vbox-dev at virtualbox.org
Subject: Re: [vbox-dev] Managing CR3 on
guest O.S.

Hi Francesco.



On Jul 23, 2011, at 4:02 PM, Francesco
Di Paolo wrote:





Hello
there,
i'd like some hints in regards how the CR3 register is
handled. From what i've learned, it seems that VirtualBox, everytime
a guest O.S. try to write on CR3. generates a #GP and 
uses a
function EMInterpretCRxWrite() that
calls emUpdateCRx() which
modifies the
VCpu. In particular, in regards to CR3, it sets the new
value(with  CPUMSetGuestCR3 )and
does a flush calling PGMFlushTLB() that
remap the CR3 with the function MapCR3(). Now,
i  think that VirtualBox has to do the setup of the new page
table right? And, in order to catch all the exceptions, it has to
write protect it or am i wrong?and if it is so,can anyone address me
to the source code that does these??

i
would appreciate



We cache shadow paging structures. So,
when the guest loads a new value into CR3 its very likely that it
will be in our cache. The cache is called PGMPool. It will take care
of monitoring the paging structures and keeping the shadow
sufficiently up to date.



Missing entries in the shadow paging
structures will mostly be synced over from the guest structures when
a page fault occurs, i.e. when they normally would be loaded into the
CPUs TLB.



-- 

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


_______________________________________________
vbox-dev mailing list vbox-dev at virtualbox.org
http://vbox.innotek.de/mailman/listinfo/vbox-dev



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


More information about the vbox-dev mailing list