From mboxrd@z Thu Jan 1 00:00:00 1970 From: Huang Ying Subject: Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address Date: Fri, 12 Nov 2010 09:16:48 +0800 Message-ID: <1289524608.8719.1066.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> <1289436982.8719.86.camel@yhuang-dev> <4CDBB9C2.6080608@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Marcelo Tosatti , "kvm@vger.kernel.org" , Andi Kleen , Dean Nelson , Luiz Capitulino To: Avi Kivity Return-path: Received: from mga11.intel.com ([192.55.52.93]:18264 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754001Ab0KLBQu (ORCPT ); Thu, 11 Nov 2010 20:16:50 -0500 In-Reply-To: <4CDBB9C2.6080608@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 2010-11-11 at 17:39 +0800, Avi Kivity wrote: > 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) Poisoning includes: a) gva -> gpa b) gpa -> hva c) hva -> hpa d) inject the MCE into host via some external tool poison-address need to do b, c, d. Do you think it is good to do all these inside qemu? > 4) Use -mempath on /dev/shm and poison a page in the backing file If we can poison a page in the backing file, how do we know the corresponding gpa and hpa? Best Regards, Huang Ying