Re: [Xen-devel] page table question!

[tgh <wwwwww4187@xxxxxxxxxxx>]

hi
In the HVM mode on the AMD NPT or intel EPT,VMM should maintain a 
counterpart pagetable for each of the guestOS process's page table, is 
it ? then there will not be a small mount of memory consumption for 
hyperviser's limited VA ,is it? or where are those counterpart page 
tables stored ?
Thanks in advance




Tim Deegan 写道:
> At 17:35 +0100 on 13 Jun (1181756130), Mark Williamson wrote:
>   
> > > > 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.
> > > >         
> > > Good question. I have a feeling that the answer is "it doesn't". HAP
> > > would probably solve this problem.
> > >       
> 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.
>
>   
> > Don't guests need the dirty bits for their memory management (e.g. mmap) to 
> > work correctly? 
> >     
> 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. :)
>
>   
> > Maybe one could do something scary like trapping reads to 
> > guest PTEs, enabling Xen to refer to the real PTE...  Sounds a bit gross 
> > though.
> >     
> It was considered. :)  (For good reasons; talk to Michael Fetterman
> some time.)
>
>   
> > HAP is definitely HAPpier :-)
> >     
> Yep, should see a significant performance increase and eliminate a lot
> of moving parts.
>
> Tim.
>
>   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel