From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Hu Yaohui <loki2441@gmail.com>
Cc: Gleb Natapov <gleb@kernel.org>,
avi.kivity@gmail.com, Marcelo Tosatti <mtosatti@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection
Date: Wed, 26 Mar 2014 12:54:40 +0800 [thread overview]
Message-ID: <53325D90.80808@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAHqbYQuOM4CmJGR7aT7_b6XCoYtUvqHmhxYKynF5_ABW10LDVQ@mail.gmail.com>
A suggestion: please send a new mail to ask question, especially,
when your question is not related to the patches, so that others
will probably discover the topic and join the discussion.
On 03/26/2014 12:25 AM, Hu Yaohui wrote:
> Hi Guangrong,
> Since you have written in the kvm/mmu.txt.
> <quote>
>
> unsync:
> If true, then the translations in this page may not match the guest's
> translation. This is equivalent to the state of the tlb when a pte is
> changed but before the tlb entry is flushed. Accordingly, unsync ptes
> are synchronized when the guest executes invlpg or flushes its tlb by
> other means. Valid for leaf pages.
>
> </quote>
>
> This make sense to me, my question is when those unsync bits will be
> set? When the guest writes to the level 1 guest page tables, it will
> not cause a page fault. Those unsync bit is unlikely to be set when
> the entry is modified. (correct me if I am wrong).
The bit is set in mmu_need_write_protect() where the host makes decision
if the page need to be write-protected (!unsync) or to be unsynced.
prev parent reply other threads:[~2014-03-26 4:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 14:01 [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection Xiao Guangrong
2014-03-10 14:01 ` [PATCH 1/5] Revert "KVM: Simplify kvm->tlbs_dirty handling" Xiao Guangrong
2014-03-10 14:01 ` [PATCH 2/5] KVM: MMU: properly check last spte in fast_page_fault() Xiao Guangrong
2014-03-10 14:01 ` [PATCH 3/5] KVM: MMU: lazily drop large spte Xiao Guangrong
2014-03-10 14:01 ` [PATCH 4/5] KVM: MMU: flush tlb if the spte can be locklessly modified Xiao Guangrong
2014-03-10 14:01 ` [PATCH 5/5] KVM: MMU: flush tlb out of mmu lock when write-protect the sptes Xiao Guangrong
2014-04-09 14:51 ` Marcelo Tosatti
2014-04-15 11:11 ` Xiao Guangrong
2014-03-25 3:29 ` [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection Xiao Guangrong
2014-03-25 10:22 ` Paolo Bonzini
2014-03-25 16:25 ` Hu Yaohui
2014-03-26 4:40 ` Hu Yaohui
2014-03-26 5:07 ` Xiao Guangrong
2014-03-26 5:30 ` Hu Yaohui
2014-03-26 4:54 ` Xiao Guangrong [this message]
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=53325D90.80808@linux.vnet.ibm.com \
--to=xiaoguangrong@linux.vnet.ibm.com \
--cc=avi.kivity@gmail.com \
--cc=gleb@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loki2441@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).