On Tue, Jul 30, 2013 at 09:02:04PM +0800, Xiao Guangrong wrote: > Relax the tlb flush condition since we will write-protect the spte out of mmu > lock. Note lockless write-protection only marks the writable spte to readonly > and the spte can be writable only if both SPTE_HOST_WRITEABLE and > SPTE_MMU_WRITEABLE are set (that are tested by spte_is_locklessly_modifiable) > > This patch is used to avoid this kind of race: > > VCPU 0 VCPU 1 > lockless wirte protection: > set spte.w = 0 > lock mmu-lock > > write protection the spte to sync shadow page, > see spte.w = 0, then without flush tlb > > unlock mmu-lock > > !!! At this point, the shadow page can still be > writable due to the corrupt tlb entry > Flush all TLB > > Signed-off-by: Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx> > --- > arch/x86/kvm/mmu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c > index 58283bf..5a40564 100644 > --- a/arch/x86/kvm/mmu.c > +++ b/arch/x86/kvm/mmu.c > @@ -600,7 +600,8 @@ static bool mmu_spte_update(u64 *sptep, u64 new_spte) > * we always atomicly update it, see the comments in > * spte_has_volatile_bits(). > */ > - if (is_writable_pte(old_spte) && !is_writable_pte(new_spte)) > + if (spte_is_locklessly_modifiable(old_spte) && > + !is_writable_pte(new_spte)) > ret = true; This will needlessly flush tlbs when dirty login is not in use (common case) and old spte is non writable. Can you estimate how serious the performance hit is? > > if (!shadow_accessed_mask) > -- > 1.8.1.4 -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
