From mboxrd@z Thu Jan  1 00:00:00 1970
From: Huang Ying <ying.huang@intel.com>
Subject: Re: [PATCH  -v2] Monitor command: pfa2hva, translate guest
	physical address to host virtual address
Date: Thu, 11 Nov 2010 00:56:22 +0000
Message-ID: <1289436982.8719.86.camel@yhuang-dev>
References: <1288060789.2862.336.camel@yhuang-dev>
	 <20101101160952.GE1429@amt.cnet>	<4CCF0BAB.9000304@linux.vnet.ibm.com>
	 <1288639205.2059.34.camel@yhuang-mobile>
	 <4CCF136D.5080307@linux.vnet.ibm.com>	<4CD58121.2040209@redhat.com>
	 <1289179768.3532.3.camel@yhuang-dev>	<4CD770E5.9000105@linux.vnet.ibm.com>
	 <4CDA421C.2040308@redhat.com> <1289377270.8719.66.camel@yhuang-dev>
	 <4CDA5911.1080006@redhat.com>  <4CDACD33.8040800@linux.vnet.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Avi Kivity <avi@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Andi Kleen <andi@firstfloor.org>,
	Dean Nelson <dnelson@redhat.com>,
	Luiz Capitulino <lcapitulino@redhat.com>
To: Anthony Liguori <aliguori@linux.vnet.ibm.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mga01.intel.com ([192.55.52.88]:7180 "EHLO mga01.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932171Ab0KKA4b (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 10 Nov 2010 19:56:31 -0500
In-Reply-To: <4CDACD33.8040800@linux.vnet.ibm.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Thu, 2010-11-11 at 00:49 +0800, Anthony Liguori wrote:
> On 11/10/2010 02:34 AM, Avi Kivity wrote:
> >> Why the gpa ->  hva mapping is not
> >> consistent for RAM if -mempath is not used?
> >
> > Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas 
> > (while remaining in the same hva).
> >
> > Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not 
> > sure we want to guarantee that it won't.
> 
> We can't universally either.  Memory hot remove potentially breaks the 
> mapping and some non-x86 architectures (like ARM) can alias RAM via a 
> guest triggered mechanism.

Thanks for clarification. Now I think we have two options.

1) Clearly mark gpa2hva (pfa2hva now, should renamed to gpa2hva) as a
testing only interface, and should be used only on restricted
environment (normal memory, without hot-remove, maybe only on x86).

2) Find some way to lock the gpa -> hva mapping during operating. Such
as gpa2hva_begin and gpa2hva_end and lock the mapping in between.

I think 2) may be possible. But if there are no other users, why do that
for a test case? So I think 1) may be the better option.

Best Regards,
Huang Ying