From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Subject: Re: [PATCH 1/3] KVM: PPC: e500: Call kvmppc_mmu_map for initial
 mapping
Date: Thu, 17 Jan 2013 18:35:34 -0600
Message-ID: <1358469334.13978.20@snotra>
References: <1358467877.13978.18@snotra>
	<F75E090F-2AE5-483E-BCDE-E9FAED2415ED@suse.de>
	<6F53F898-0DF7-4CBD-8204-1A34F2E82D6E@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed
Content-Transfer-Encoding: 8BIT
Cc: <kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>
To: Alexander Graf <agraf@suse.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from tx2ehsobe004.messaging.microsoft.com ([65.55.88.14]:35007 "EHLO
	tx2outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752472Ab3ARAgf convert rfc822-to-8bit
	(ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 17 Jan 2013 19:36:35 -0500
In-Reply-To: <6F53F898-0DF7-4CBD-8204-1A34F2E82D6E@suse.de> (from
	agraf@suse.de on Thu Jan 17 18:29:56 2013)
Content-Disposition: inline
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 01/17/2013 06:29:56 PM, Alexander Graf wrote:
> 
> On 18.01.2013, at 01:20, Alexander Graf wrote:
> 
> >
> > On 18.01.2013, at 01:11, Scott Wood wrote:
> >
> >> It also seems like it would be cleaner to just invalidate the old  
> entry
> >> in tlbwe, and then this function doesn't need to change at all.  I  
> am a
> >> bit confused by how invalidation is currently operating
> 
> Well, this bit is obvious. It's done by kvmppc_e500_shadow_map when  
> it calls kvmppc_e500_ref_release(), right?
> 
> Why it's not done explicitly though is a really good question :).

Yeah, I saw that but considered it (in combination with not reaching  
this function if the gtlbe is invalid, and with always preloading the  
host entry when the guest does tlbwe) to be why we're getting away with  
it rather than why it was done that way.

-Scott