From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NeA2c-0002nF-J2 for qemu-devel@nongnu.org; Sun, 07 Feb 2010 11:31:22 -0500 Received: from [199.232.76.173] (port=51865 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeA2b-0002n3-6F for qemu-devel@nongnu.org; Sun, 07 Feb 2010 11:31:21 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NeA2a-00089r-G3 for qemu-devel@nongnu.org; Sun, 07 Feb 2010 11:31:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60277) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NeA2a-00089d-3N for qemu-devel@nongnu.org; Sun, 07 Feb 2010 11:31:20 -0500 Message-ID: <4B6EEAC7.7040900@redhat.com> Date: Sun, 07 Feb 2010 18:31:03 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [Patch] Support translating Guest physical address to Host virtual address. References: <4B60B28A.40400@linux.vnet.ibm.com> <1264631460.29051.35.camel@w-amax.beaverton.ibm.com> <4B697D04.7070507@linux.vnet.ibm.com> <46D41A8912DCCF4FB93FA509BD00C63101E79CA0@irsmsx002.ger.corp.intel.com> <4B6986F6.5000808@linux.vnet.ibm.com> <46D41A8912DCCF4FB93FA509BD00C63101E79E14@irsmsx002.ger.corp.intel.com> <4B69A0DF.4040908@linux.vnet.ibm.com> <4B6EC835.3010805@redhat.com> <4B6EE8FC.9080602@codemonkey.ws> In-Reply-To: <4B6EE8FC.9080602@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "lmr@redhat.com" , "Li, Haicheng" , Max Asbock , "qemu-devel@nongnu.org" , "Zheng, Jiajia" , "You, Yongkang" , "Kleen, Andi" On 02/07/2010 06:23 PM, Anthony Liguori wrote: > On 02/07/2010 08:03 AM, Avi Kivity wrote: >> On 02/03/2010 06:14 PM, Anthony Liguori wrote: >>>>> aren't we putting the cart before the horse here? >>>> qemu has support for triggering MCEs on the monitor. >>>> >>>> Also the KVM code base has support for forwarding the MCEs >>>> automatically. >>> >>> KVM has all of the information you need (guest physical -> host >>> physical mapping). It can also pin the mapping making it much safer >>> to interface at that level. You should probably add an ioctl >>> interface to KVM to get a host physical from a given guest physical >>> and then use that to do the MCE injection. You would need to write >>> a little helper tool and you would need a way to get an fd for an >>> existing guest. >>> >> >> It would be simpler to trigger the whole thing from within qemu. > > Only insofar as you don't have to deal with getting at the VM fd. You > can avoid the problem by having the kvm ioctl interface take a pid or > something. That's a racy interface. > > The problem I have with driving this through qemu is that it's purely > a test mechanism and it's not even one that we can verify within > qemu. It's a command that isn't really useful in anything but a very > specific context. > > I don't think it's the right thing to do to add dozens of monitor > commands to enable test harnesses that are not related to actual > functionality within qemu. Well, we need to provide a reasonable alternative. One might be to use -mempath (which is hacky by itself, but so far we have no alternative) and use an external tool on the memory object to poison it. An advantage is that you can use it independently of kvm. -- error compiling committee.c: too many arguments to function