Re: page table question!

[tgh <wwwwww4187@sina.com.cn>]

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.
>
>