From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address Date: Thu, 11 Nov 2010 11:39:14 +0200 Message-ID: <4CDBB9C2.6080608@redhat.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> <4CDACD33.8040800@linux.vnet.ibm.com> <1289436982.8719.86.camel@yhuang-dev> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Marcelo Tosatti , "kvm@vger.kernel.org" , Andi Kleen , Dean Nelson , Luiz Capitulino To: Huang Ying Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14791 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753058Ab0KKJjX (ORCPT ); Thu, 11 Nov 2010 04:39:23 -0500 In-Reply-To: <1289436982.8719.86.camel@yhuang-dev> Sender: kvm-owner@vger.kernel.org List-ID: On 11/11/2010 02:56 AM, Huang Ying wrote: > 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. > 3) Move the poisoning code into qemu, so the command becomes posison-address (though physical addresses aren't stable either) 4) Use -mempath on /dev/shm and poison a page in the backing file (if poisoning works on tmpfs) -- error compiling committee.c: too many arguments to function