On 06/09/2011 03:07 PM, Avi Kivity wrote:
> On 06/07/2011 04:03 PM, Xiao Guangrong wrote:
>> Split kvm_mmu_free_page to kvm_mmu_free_lock_parts and
>> kvm_mmu_free_unlock_parts
>>
>> One is used to free the parts which is under mmu lock and the other is
>> used to free the parts which can allow be freed out of mmu lock
>>
>> It is used by later patch
>
> Suggest kvm_mmu_isolate_page() and kvm_mmu_free_page(). Plus a comment explaining things, unless someone can come up with a better name.
>
Good names, will fix.
>> -static void kvm_mmu_free_page(struct kvm_mmu_page *sp)
>> +static void kvm_mmu_free_lock_parts(struct kvm_mmu_page *sp)
>> {
>> ASSERT(is_empty_shadow_page(sp->spt));
>> hlist_del(&sp->hash_link);
>> - list_del(&sp->link);
>> - free_page((unsigned long)sp->spt);
>> if (!sp->role.direct)
>> free_page((unsigned long)sp->gfns);
>> +}
>> +
>> +static void kvm_mmu_free_unlock_parts(struct kvm_mmu_page *sp)
>> +{
>> + list_del(&sp->link);
>> + free_page((unsigned long)sp->spt);
>> kmem_cache_free(mmu_page_header_cache, sp);
>> }
>
> The list_del() must be run under a lock, no? it can access kvm->arch.active_mmu_pages.
>
In prepare path, we have moved the sp from active_mmu_pages to invlaid_list.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
