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: Sun, 14 Nov 2010 13:08:56 +0200 Message-ID: <4CDFC348.5050400@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> <4CDBB9C2.6080608@redhat.com> <1289524608.8719.1066.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]:14772 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755100Ab0KNLJU (ORCPT ); Sun, 14 Nov 2010 06:09:20 -0500 In-Reply-To: <1289524608.8719.1066.camel@yhuang-dev> Sender: kvm-owner@vger.kernel.org List-ID: On 11/12/2010 03:16 AM, Huang Ying wrote: > 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? If d is not too complicated (an ioctl?), we might to it in 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? I think you currently can't know it's gpa (why do you want to?); the upcoming NUMA enhancements should allow this (the plan is to have a file per guest NUMA node, so we can tell the host what policy to apply for that node). gpa->hpa translation can be derived from /proc/pid/maps. -- error compiling committee.c: too many arguments to function