linux-kernel - Re: [RFC PATCH 00/12] KVM: MMU: locklessly wirte-protect

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: <C5B92ED2-6055-40A7-88FD-7425AFC1A626@gmail.com>
Date:	Sun, 4 Aug 2013 22:15:05 +0800
From:	Xiao Guangrong <xiaoguangrong.eric@...il.com>
To:	Takuya Yoshikawa <takuya.yoshikawa@...il.com>
Cc:	Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>,
	"gleb@...hat.com Natapov" <gleb@...hat.com>, avi.kivity@...il.com,
	mtosatti@...hat.com,
	"pbonzini@...hat.com Bonzini" <pbonzini@...hat.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [RFC PATCH 00/12] KVM: MMU: locklessly wirte-protect


On Aug 3, 2013, at 1:09 PM, Takuya Yoshikawa <takuya.yoshikawa@...il.com> wrote:

> On Tue, 30 Jul 2013 21:01:58 +0800
> Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com> wrote:
> 
>> Background
>> ==========
>> Currently, when mark memslot dirty logged or get dirty page, we need to
>> write-protect large guest memory, it is the heavy work, especially, we need to
>> hold mmu-lock which is also required by vcpu to fix its page table fault and
>> mmu-notifier when host page is being changed. In the extreme cpu / memory used
>> guest, it becomes a scalability issue.
>> 
>> This patchset introduces a way to locklessly write-protect guest memory.
> 
> Nice improvements!

Thank you!

> 
> If I read the patch set correctly, this work contains the following changes:
> 
> Cleanups:
>        Patch 1 and patch 12.
> 
> Lazy large page dropping for dirty logging:
>        Patch 2-3.
>        Patch 2 is preparatory to patch 3.
> 
>        This does not look like an RFC if you address Marcelo's comment.
>        Any reason to include this in an RFC patch set?

Right, these two patches are not really RFC since you guys have reviewed the
idea.

The reason i put these into this patchset is that they are also the preparing work
for implementing lockless writ-protection since after that we do not need to
remove a spte from the rmap any more. (only need to write-protect a spte.)

> 
> Making remote TLBs flushable outside of mmu_lock for dirty logging:
>        Patch 6.
> 
>        This is nice.  I'm locally using a similar patch for my work, but yours
>        is much cleaner and better.  I hope this will get merged soon.

Thanks!

> 
> New Pte-list handling:
>        Patch 7-9.
> 
>        Still reading the details.
> 
> RCU-based lockless write protection.
>        Patch 10-11.
> 
>        If I understand RCU correctly, the current implementation has a problem:
>        read-side critical sections can become too long.
> 
>        See the following LWN's article:
>        "Sleepable RCU"
>        https://lwn.net/Articles/202847/
> 
>        Especially, kvm_mmu_slot_remove_write_access() can take hundreds of
>        milliseconds, or even a few seconds for guests using shadow paging.
>        Is it possible to break the read-side critical section after protecting
>        some pages? -- I guess so.

Yes. we can use the break-tech in the code if it is needed, like this:

if (need_resched()) {
	kvm_use_rcu_free_page_end();
	kvm_use_rcu_free_page_begin();
}

> 
> Anyway, I want to see the following non-RFC quality patches get merged first:
>        - Lazy large page dropping for dirty logging:
>        - Making remote TLBs flushable outside of mmu_lock for dirty logging
> 
> As you are doing in patch 11, the latter can eliminate the TLB flushes before
> cond_resched_lock().  So this alone is an optimization, and since my work is
> based on this TLB flush-less lock breaking, I would appriciate if you make this
> change first in your clean way.

Okay, i will move these patches to the front then the maintainers can merge
them easily.

> 
> The remaining patches, pte-list refactoring and lock-less ones, also look
> interesting, but I need to read more to understand them.
> 
> Thanks for the nice work!

Thanks for your review and the comments! :)

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