All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: gleb@redhat.com, avi.kivity@gmail.com, mtosatti@redhat.com,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 2/7] KVM: MMU: document clear_spte_count
Date: Wed, 19 Jun 2013 20:25:46 +0800	[thread overview]
Message-ID: <51C1A34A.7080201@linux.vnet.ibm.com> (raw)
In-Reply-To: <51C19C4C.3000800@redhat.com>

On 06/19/2013 07:55 PM, Paolo Bonzini wrote:
> Il 19/06/2013 13:53, Xiao Guangrong ha scritto:
>> On 06/19/2013 07:32 PM, Paolo Bonzini wrote:
>>> Il 19/06/2013 11:09, Xiao Guangrong ha scritto:
>>>> Document it to Documentation/virtual/kvm/mmu.txt
>>>
>>> While reviewing the docs, I looked at the code.
>>>
>>> Why can't this happen?
>>>
>>>     CPU 1: __get_spte_lockless          CPU 2: __update_clear_spte_slow
>>> ------------------------------------------------------------------------------
>>>                                         write low
>>>     read count
>>>     read low
>>>     read high
>>>                                         write high
>>>     check low and count
>>>                                         update count
>>>
>>> The check passes, but CPU 1 read a "torn" SPTE.
>>
>> In this case, CPU 1 will read the "new low bits" and the "old high bits", right?
>> the P bit in the low bits is cleared when do __update_clear_spte_slow, i.e, it is
>> not present, so the whole value is ignored.
> 
> Indeed that's what the comment says, too.  But then why do we need the
> count at all?  The spte that is read is exactly the same before and
> after the count is updated.

In order to detect repeatedly marking spte present to stop the lockless side
to see present to present change, otherwise, we can get this:

Say spte = 0xa11110001 (high 32bits = 0xa, low 32bit = 0x11110001)

CPU 1: __get_spte_lockless          CPU 2: __update_clear_spte_slow
----------------------------------------------------------------------
read low: low= 0x11110001
                                    clear the spte, then spte = 0x0ull
read high: high = 0x0
                                    set spte to 0xb11110001 (high 32bits = 0xb,
                                    low 32bit = 0x11110001)

read low: 0x11110001 and see
it is not changed.

In this case, CPU 1 see the low bits are not changed, then it tries to access the memory at:
0x11110000.

BTW, we are using tlb to protect lockless walking, the count can be drop after
improving kvm_set_pte_rmapp where is the only place change spte from present to present
without TLB flush.


  reply	other threads:[~2013-06-19 12:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19  9:09 [PATCH 0/7] KVM: MMU: update mmu documentation Xiao Guangrong
2013-06-19  9:09 ` [PATCH 1/7] KVM: MMU: update the documentation for reverse mapping of parent_pte Xiao Guangrong
2013-06-19 10:32   ` Paolo Bonzini
2013-06-19  9:09 ` [PATCH 2/7] KVM: MMU: document clear_spte_count Xiao Guangrong
2013-06-19 11:32   ` Paolo Bonzini
2013-06-19 11:53     ` Xiao Guangrong
2013-06-19 11:55       ` Paolo Bonzini
2013-06-19 12:25         ` Xiao Guangrong [this message]
2013-06-19 12:41           ` Paolo Bonzini
2013-06-19 13:29             ` Xiao Guangrong
2013-06-19 11:40   ` Paolo Bonzini
2013-06-19 12:39     ` Xiao Guangrong
2013-06-19  9:09 ` [PATCH 3/7] KVM: MMU: document write_flooding_count Xiao Guangrong
2013-06-19 11:58   ` Paolo Bonzini
2013-06-19 12:43     ` Xiao Guangrong
2013-06-19  9:09 ` [PATCH 4/7] KVM: MMU: document mmio page fault Xiao Guangrong
2013-06-19 12:10   ` Paolo Bonzini
2013-06-19 12:59     ` Xiao Guangrong
2013-06-19  9:09 ` [PATCH 5/7] KVM: MMU: document fast page fault in Xiao Guangrong
2013-06-19 12:13   ` Paolo Bonzini
2013-06-19 13:00     ` Xiao Guangrong
2013-06-19  9:09 ` [PATCH 6/7] KVM: MMU: document fast invalidate all pages Xiao Guangrong
2013-06-19 12:25   ` Paolo Bonzini
2013-06-19 13:07     ` Xiao Guangrong
2013-06-19  9:09 ` [PATCH 7/7] KVM: MMU: document fast invalidate all mmio sptes Xiao Guangrong
2013-06-19 12:35   ` Paolo Bonzini
2013-06-19 13:10     ` Xiao Guangrong
2013-06-20  5:21   ` Rob Landley
2013-06-20  8:19     ` Paolo Bonzini
2013-06-19 17:41 ` [PATCH 0/7] KVM: MMU: update mmu documentation Paolo Bonzini

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=51C1A34A.7080201@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 \
    --cc=pbonzini@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.