From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address Date: Wed, 10 Nov 2010 10:49:55 -0600 Message-ID: <4CDACD33.8040800@linux.vnet.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Huang Ying , Marcelo Tosatti , "kvm@vger.kernel.org" , Andi Kleen , Dean Nelson , Luiz Capitulino To: Avi Kivity Return-path: Received: from e9.ny.us.ibm.com ([32.97.182.139]:43679 "EHLO e9.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756546Ab0KJQt7 (ORCPT ); Wed, 10 Nov 2010 11:49:59 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oAAGSZgj018636 for ; Wed, 10 Nov 2010 11:28:35 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oAAGnv631790040 for ; Wed, 10 Nov 2010 11:49:57 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oAAGnuPh031624 for ; Wed, 10 Nov 2010 14:49:57 -0200 In-Reply-To: <4CDA5911.1080006@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. Regards, Anthony Liguori