From mboxrd@z Thu Jan 1 00:00:00 1970 From: tgh Subject: Re: page table question! Date: Sat, 08 Dec 2007 22:26:49 +0800 Message-ID: <475AA9A9.4050103@sina.com.cn> References: <907625E08839C4409CE5768403633E0B02561E12@sefsexmb1.amd.com> <200706131735.30820.mark.williamson@cl.cam.ac.uk> <20070614082755.GB15027@york.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20070614082755.GB15027@york.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan , Mark Williamson , "Petersson, Mats" , Tim Deegan Cc: xen-devel@lists.xensource.com, MT Rezaie List-Id: xen-devel@lists.xenproject.org hi In the HVM mode on the AMD NPT or intel EPT,VMM should maintain a=20 counterpart pagetable for each of the guestOS process's page table, is=20 it ? then there will not be a small mount of memory consumption for=20 hyperviser's limited VA ,is it? or where are those counterpart page=20 tables stored ? Thanks in advance Tim Deegan =E5=86=99=E9=81=93: > At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote: > =20 >>>> One thing I've never been clear on for shadow mode is how >>>> accessed / dirty >>>> bits get propagated to the guest pagetable from the shadow. >>>> =20 >>> Good question. I have a feeling that the answer is "it doesn't". HAP >>> would probably solve this problem. >>> =20 > > When a guest pagetable entry has the Accessed bit clear, its shadow has > the Present bit clear. This means we will get an extra page fault when > the guest tries to read that area of memory. In the page-fault handler > we write the Accessed bit into the guest entry, and replace the shadow > entry with one that has the Present bit. A similar scheme (shadowing > ~Dirty with ~Writeable) applies to those entries that have Dirty bits. > > The actual moving parts are in the _sh_propagate() function in > arch/x86/mm/shadow/multi.c, which is why that function needs to be told > whether it's handling a read fault, write fault or prefetch operation. > > =20 >> Don't guests need the dirty bits for their memory management (e.g. mma= p) to=20 >> work correctly?=20 >> =20 > > Yes, although in fact Xen doesn't quite catch all the cases where those > bits should be set (certain Xen-handled operations that walk the guest > pagetables instead of using the shadows) and it's not tripped us up > yet. :) > > =20 >> Maybe one could do something scary like trapping reads to=20 >> guest PTEs, enabling Xen to refer to the real PTE... Sounds a bit gro= ss=20 >> though. >> =20 > > It was considered. :) (For good reasons; talk to Michael Fetterman > some time.) > > =20 >> HAP is definitely HAPpier :-) >> =20 > > Yep, should see a significant performance increase and eliminate a lot > of moving parts. > > Tim. > > =20