From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [PATCH -v2] Add MCE support to KVM Date: Mon, 20 Apr 2009 07:30:40 +0200 Message-ID: <20090420053040.GT14687@one.firstfloor.org> References: <1239953345.6842.3.camel@yhuang-dev.sh.intel.com> <49E9F7BE.4090904@codemonkey.ws> <1240190385.6842.45.camel@yhuang-dev.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Huang Ying , Anthony Liguori , Avi Kivity , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Andi Kleen To: Kyle Moffett Return-path: Received: from one.firstfloor.org ([213.235.205.2]:54056 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752853AbZDTF1Y (ORCPT ); Mon, 20 Apr 2009 01:27:24 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: > IMO the main reason to put this in kernel-space would be to make it > possible to automatically forward some MCE errors generated by the > real hardware (RAM ECC errors for example) down into the VM. Right > now I suppose you could do that with the patches to forward RAM-based > hard MCEs to userspace using SIGSEGV and handling the SIGSEGV in > userspace, but that seems more fragile to me. I think you refer to my hwpoison patches that generate SIGBUS? The event has to go through user space anyways. The code to generate the fake MCE from the SIGBUS is (or rather will be with current patch) in qemu. Normally the principle to process such errors as quickly as possible is sound though, although I'm not sure how much difference it makes. In theory it could be put into kernel too, but you would need a "in kernel signal handler" then, which would need quite some more changes. -Andi -- ak@linux.intel.com -- Speaking for myself only.