From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH 3/5] KVM: PPC: Book3S HV: Handle memory slot deletion and
 modification correctly
Date: Fri, 24 Aug 2012 15:58:29 -0300
Message-ID: <20120824185829.GA24107@amt.cnet>
References: <20120811003754.GA6016@bloggs.ozlabs.ibm.com>
 <20120813163411.GA22134@amt.cnet>
 <20120813220450.GB15395@amt.cnet>
 <502B6B2D.2060906@redhat.com>
 <20120815175920.GB18452@amt.cnet>
 <1345187178.11751.49.camel@pasglop>
 <20120817183939.GA26687@amt.cnet>
 <1345235545.11751.89.camel@pasglop>
 <20120823135537.GC4747@amt.cnet>
 <20120824092953.GC7051@bloggs.ozlabs.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Avi Kivity <avi@redhat.com>, Gleb Natapov <gleb@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>,
	Alexander Graf <agraf@suse.de>, kvm-ppc@vger.kernel.org,
	kvm@vger.kernel.org
To: Paul Mackerras <paulus@samba.org>
Return-path: <kvm-ppc-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20120824092953.GC7051@bloggs.ozlabs.ibm.com>
Sender: kvm-ppc-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On Fri, Aug 24, 2012 at 07:29:53PM +1000, Paul Mackerras wrote:
> On Thu, Aug 23, 2012 at 10:55:37AM -0300, Marcelo Tosatti wrote:
> 
> > There are a number of options to consider:
> > 
> > 1) Merge the current patchset from Paul, which has two downsides:
> > 	1-1) It contains an unfixable race.
> 
> The race being that new HTPEs using the old base address could get
> inserted after we flush the old HPTEs and before we update the memslot
> array?

Yes. That race, for the slot deletion case, is fixed by RCU assignment 
of memslot marked with KVM_MEMSLOT_INVALID.

For the base change case, x86 flushes all translations via the
kvm_arch_flush_shadow() at the of __kvm_set_memory. 

Which is not enough for PPC since you need to flush _before_ new
memslot is visible.

> I think we could solve that one by temporarily marking the memslot
> invalid for changes of base_gfn as well as for memslot deletions.  Can
> you see any problem with that?  It means that guest accesses to the
> old memslot addresses would trap or fail, but if the guest is trying
> to access a device while its BAR is being changed, then I think it
> deserves that.

No, i don't see any problem with that. Sent a patchset.