linux-kernel - Re: [PATCH 2/5] KVM: MMU: split the operations of kvm_mmu_zap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C039816.5090101@redhat.com>
Date:	Mon, 31 May 2010 14:05:58 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Xiao Guangrong <xiaoguangrong@...fujitsu.com>
CC:	Marcelo Tosatti <mtosatti@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	KVM list <kvm@...r.kernel.org>
Subject: Re: [PATCH 2/5] KVM: MMU: split the operations of kvm_mmu_zap_page()

On 05/31/2010 05:13 AM, Xiao Guangrong wrote:
>
> Avi Kivity wrote:
>    
>> On 05/30/2010 03:37 PM, Xiao Guangrong wrote:
>>      
>>> Using kvm_mmu_prepare_zap_page() and kvm_mmu_commit_zap_page() to
>>> split kvm_mmu_zap_page() function, then we can:
>>>
>>> - traverse hlist safely
>>> - easily to gather remote tlb flush which occurs during page zapped
>>>
>>>
>>> +static int kvm_mmu_prepare_zap_page(struct kvm *kvm, struct
>>> kvm_mmu_page *sp)
>>> +{
>>> +    int ret;
>>> +
>>> +    trace_kvm_mmu_zap_page(sp);
>>> +    ++kvm->stat.mmu_shadow_zapped;
>>> +    ret = mmu_zap_unsync_children(kvm, sp);
>>> +    kvm_mmu_page_unlink_children(kvm, sp);
>>> +    kvm_mmu_unlink_parents(kvm, sp);
>>> +    if (!sp->role.invalid&&   !sp->role.direct)
>>> +        unaccount_shadowed(kvm, sp->gfn);
>>> +    if (sp->unsync)
>>> +        kvm_unlink_unsync_page(kvm, sp);
>>> +    if (!sp->root_count)
>>> +        /* Count self */
>>> +        ret++;
>>> +    else
>>> +        kvm_reload_remote_mmus(kvm);
>>> +
>>> +    sp->role.invalid = 1;
>>> +    list_move(&sp->link,&kvm->arch.invalid_mmu_pages);
>>> +    kvm_mmu_reset_last_pte_updated(kvm);
>>> +    return ret;
>>> +}
>>> +
>>> +static void kvm_mmu_commit_zap_page(struct kvm *kvm)
>>> +{
>>> +    struct kvm_mmu_page *sp, *n;
>>> +
>>> +    if (list_empty(&kvm->arch.invalid_mmu_pages))
>>> +        return;
>>> +
>>> +    kvm_flush_remote_tlbs(kvm);
>>> +    list_for_each_entry_safe(sp, n,&kvm->arch.invalid_mmu_pages, link) {
>>> +        WARN_ON(!sp->role.invalid);
>>> +        if (!sp->root_count)
>>> +            kvm_mmu_free_page(kvm, sp);
>>> +    }
>>> +}
>>> +
>>>
>>>        
>> You're adding two new functions but not using them here?  Possibly in
>> the old kvm_mmu_zap_page()?
>>      
> I use those in the next patch, it's not in kvm_mmu_zap_page(), it's used like:
>
> hold mmu spin lock
>
> kvm_mmu_prepare_zap_page page A
> kvm_mmu_prepare_zap_page page B
> kvm_mmu_prepare_zap_page page C
> ......
> kvm_mmu_commit_zap_page
>    

It would be better to rewrite kvm_mmu_zap_page() in terms of 
prepare/commit in the patch so we don't have two copies of the same 
thing (also easier to review).




>> This is a good idea, but belongs in a separate patch?  We can use it to
>> reclaim invalid pages before allocating new ones.
>>
>>      
> This patch is very simple and kvm_mmu_commit_zap_page() function should depend on
> kvm->arch.invalid_mmu_pages, so i think we on need separate this patch, your opinion? :-)
>
>    

How about passing the list as a parameter to prepare() and commit()?  If 
the lifetime of the list is just prepare/commit, it shouldn't be a global.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/