public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: mtosatti@redhat.com, avi.kivity@gmail.com,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v3 08/15] KVM: MMU: allow unmap invalid rmap out of mmu-lock
Date: Thu, 18 Apr 2013 19:22:23 +0800	[thread overview]
Message-ID: <516FD76F.6090306@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130418110036.GS8997@redhat.com>

On 04/18/2013 07:00 PM, Gleb Natapov wrote:
> On Tue, Apr 16, 2013 at 02:32:46PM +0800, Xiao Guangrong wrote:
>> pte_list_clear_concurrently allows us to reset pte-desc entry
>> out of mmu-lock. We can reset spte out of mmu-lock if we can protect the
>> lifecycle of sp, we use this way to achieve the goal:
>>
>> unmap_memslot_rmap_nolock():
>> for-each-rmap-in-slot:
>>       preempt_disable
>>       kvm->arch.being_unmapped_rmap = rmapp
>>       clear spte and reset rmap entry
>>       kvm->arch.being_unmapped_rmap = NULL
>>       preempt_enable
>>
>> Other patch like zap-sp and mmu-notify which are protected
>> by mmu-lock:
>>       clear spte and reset rmap entry
>> retry:
>>       if (kvm->arch.being_unmapped_rmap == rmap)
>> 		goto retry
>> (the wait is very rare and clear one rmap is very fast, it
>> is not bad even if wait is needed)
>>
> I do not understand what how this achieve the goal. Suppose that rmap
> == X and kvm->arch.being_unmapped_rmap == NULL so "goto retry" is skipped,
> but moment later unmap_memslot_rmap_nolock() does
> vm->arch.being_unmapped_rmap = X.

Access rmap is always safe since rmap and its entries are valid until
memslot is destroyed.

This algorithm protects spte since it can be freed in the protection of mmu-lock.

In your scenario:

======
   CPU 1                                      CPU 2

vcpu / mmu-notify access the RMAP         unmap rmap out of mmu-lock which is under
which is under mmu-lock                   slot-lock

zap spte1
clear RMAP entry

kvm->arch.being_unmapped_rmap = NULL,
do not wait

free spte1

                                        set kvm->arch.being_unmapped_rmap = RMAP
                                        walking RMAP and do not see spet1 on RMAP
                                        (the entry of spte 1 has been reset by CPU 1)
                                        set kvm->arch.being_unmapped_rmap = NULL
======

That protect CPU 2 can not access the freed-spte.

  reply	other threads:[~2013-04-18 11:22 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16  6:32 [PATCH v3 00/15] KVM: MMU: fast zap all shadow pages Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 01/15] KVM: x86: clean up and optimize for kvm_arch_free_memslot Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 02/15] KVM: fold kvm_arch_create_memslot into kvm_arch_prepare_memory_region Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 03/15] KVM: x86: do not reuse rmap when memslot is moved Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 04/15] KVM: MMU: abstract memslot rmap related operations Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 05/15] KVM: MMU: allow per-rmap operations Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 06/15] KVM: MMU: allow concurrently clearing spte on remove-only pte-list Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 07/15] KVM: MMU: introduce invalid rmap handlers Xiao Guangrong
2013-04-17 23:38   ` Marcelo Tosatti
2013-04-18  3:15     ` Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 08/15] KVM: MMU: allow unmap invalid rmap out of mmu-lock Xiao Guangrong
2013-04-18 11:00   ` Gleb Natapov
2013-04-18 11:22     ` Xiao Guangrong [this message]
2013-04-18 11:38       ` Gleb Natapov
2013-04-18 12:10         ` Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 09/15] KVM: MMU: introduce free_meslot_rmap_desc_nolock Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 10/15] KVM: x86: introduce memslot_set_lpage_disallowed Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 11/15] KVM: MMU: introduce kvm_clear_all_lpage_info Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 12/15] KVM: MMU: fast invalid all shadow pages Xiao Guangrong
2013-04-18  0:05   ` Marcelo Tosatti
2013-04-18  4:00     ` Xiao Guangrong
2013-04-18 13:03       ` Marcelo Tosatti
2013-04-18 13:29         ` Marcelo Tosatti
2013-04-18 15:20           ` Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 13/15] KVM: x86: use the fast way to invalid all pages Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 14/15] KVM: move srcu_read_lock/srcu_read_unlock to arch-specified code Xiao Guangrong
2013-04-16  6:32 ` [PATCH v3 15/15] KVM: MMU: replace kvm_zap_all with kvm_mmu_invalid_all_pages Xiao Guangrong
2013-04-18  0:08   ` Marcelo Tosatti
2013-04-18  4:03     ` Xiao Guangrong
2013-04-20 17:18       ` Marcelo Tosatti
2013-04-21  6:59         ` Xiao Guangrong
2013-04-21 13:03 ` [PATCH v3 00/15] KVM: MMU: fast zap all shadow pages Gleb Natapov
2013-04-21 14:09   ` Xiao Guangrong
2013-04-21 15:24     ` Marcelo Tosatti
2013-04-22  2:50       ` Xiao Guangrong
2013-04-22  9:21     ` Gleb Natapov
2013-04-23  0:19       ` Xiao Guangrong
2013-04-23  6:28         ` Gleb Natapov
2013-04-23  7:20           ` Xiao Guangrong
2013-04-23  7:33             ` Gleb Natapov
2013-04-21 15:27   ` Marcelo Tosatti
2013-04-21 15:35     ` Marcelo Tosatti
2013-04-22 12:39       ` Gleb Natapov
2013-04-22 13:45         ` Takuya Yoshikawa
2013-04-22 23:02           ` Marcelo Tosatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=516FD76F.6090306@linux.vnet.ibm.com \
    --to=xiaoguangrong@linux.vnet.ibm.com \
    --cc=avi.kivity@gmail.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox