Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi:
>> I noticed the current MMU data structure is defined as per VCPU
>> such as:
>>
>> struct kvm_vcpu {
>> .....
>> struct list_head free_pages;
>> struct kvm_mmu_page page_header_buf[KVM_NUM_MMU_PAGES];
>> ..... }
>>
>> This is a hot topics in Xen development time: whether should we
>> support global shadow PT or per VCPU shadow PT? Per VCPU shadow is
>> much close to native from architecture point of view, but definitely
>> much complicated in implementation. Do we really need to implement
>> per VCPU shadow? Xen today is still global shadow.
>> If global shadow is good enough, then I will try to move
>> free_pages and page_header_buf[KVM_NUM_MMU_PAGES] to struct kvm.
>> Comments?
>>
>
> I think a global shadow is actually better. Consider a multithreaded
> application where threads are free to migrate (e.g. many more threads
> than vcpus); a per-vcpu shadow will cause many more faults
> than a global
> shadow.
Yep, we are on same page :-)
>
> I have patch that converts page_header_buf into a slab cache; that
> should remove the per-vcpu fields. I just have to debug it
> before I can
> apply it. I'll dig it up.
Great! then the shadow is almost SMP support free with big lock at
beginning.
>
> (the reason they are actually in kvm_vcpu is that we started with a
> non-caching mmu implementation, where you can't share pages anyway)
>
Eddie
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
