From mboxrd@z Thu Jan  1 00:00:00 1970
From: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Subject: Re: [RFC] need to improve slot creation/destruction? -- Re:
 [RFC][PATCH] srcu: Implement call_srcu()
Date: Fri, 10 Feb 2012 22:25:13 +0900
Message-ID: <20120210222513.7a8919f2f73604ca25c58bbd@gmail.com>
References: <1328016724.2446.229.camel@twins>
	<4F27F0E6.1040309@redhat.com>
	<1328017807.2446.230.camel@twins>
	<20120131222447.GH2391@linux.vnet.ibm.com>
	<1328091749.2760.34.camel@laptop>
	<4F29178A.1090306@redhat.com>
	<4F2918D5.4050104@redhat.com>
	<20120201135020.GB18998@amt.cnet>
	<20120209004320.5772daa0472aef4700dab1b6@gmail.com>
	<4F33D6C9.2070403@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: mtosatti@redhat.com, kvm@vger.kernel.org
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-tul01m020-f174.google.com ([209.85.214.174]:51825 "EHLO
	mail-tul01m020-f174.google.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1754361Ab2BJNZS (ORCPT
	<rfc822;kvm@vger.kernel.org>); Fri, 10 Feb 2012 08:25:18 -0500
Received: by obcva7 with SMTP id va7so3776108obc.19
        for <kvm@vger.kernel.org>; Fri, 10 Feb 2012 05:25:17 -0800 (PST)
In-Reply-To: <4F33D6C9.2070403@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Avi Kivity <avi@redhat.com> wrote:

> > 2. When we create(and shift?) a memory slot, we call kvm_arch_flush_shadow()
> > to clear all mmio sptes, again not restricted to that slot.
> >
> > 	/*
> > 	 * If the new memory slot is created, we need to clear all
> > 	 * mmio sptes.
> > 	 */
> > 	if (npages && old.base_gfn != mem->guest_phys_addr >> PAGE_SHIFT)
> > 		kvm_arch_flush_shadow(kvm);
> 
> This is pretty rare outside the previous scenario (memory/pci hotplug).

Is this condition correct?

When npages != 0 and old.npages == 0, the slot is being newly created, do we
really need to flush shadow pages?

This should be
	if (npages && old.npages && (old.base_gfn != base_gfn))
No?

	Takuya