[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53325D90.80808@linux.vnet.ibm.com>
Date: Wed, 26 Mar 2014 12:54:40 +0800
From: Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
To: Hu Yaohui <loki2441@...il.com>
CC: Gleb Natapov <gleb@...nel.org>, avi.kivity@...il.com,
Marcelo Tosatti <mtosatti@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kvm <kvm@...r.kernel.org>
Subject: Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write
protection
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.
--
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/
Powered by blists - more mailing lists