From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Add MCE support to KVM Date: Sun, 19 Apr 2009 11:33:58 +0300 Message-ID: <49EAE1F6.9050205@redhat.com> References: <1239155601.6384.3.camel@yhuang-dev.sh.intel.com> <49DE195D.1020303@redhat.com> <1239332455.6384.108.camel@yhuang-dev.sh.intel.com> <49E08762.1010206@redhat.com> <1239590499.6384.4016.camel@yhuang-dev.sh.intel.com> <49E337D7.5050502@redhat.com> <49EA515C.9000507@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Huang Ying , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Andi Kleen To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:34855 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751966AbZDSIeO (ORCPT ); Sun, 19 Apr 2009 04:34:14 -0400 In-Reply-To: <49EA515C.9000507@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > Avi Kivity wrote: >> >> Then we would need to tell which read-only MSRs are setup writeable >> and which aren't... >> >> I'm okay with an ioctl to setup MCE, but just make sure userspace has >> all the information to know what the kernel can do rather than the >> try-and-see-if-it-works approach. We can publish this information >> via KVM_CAP things, or via another ioctl (see >> KVM_GET_SUPPORTED_CPUID2 for an example). > > Why not introduce a new exit type for MSR reads/writes that aren't > handled by the kernel? You just need a bit on the return that > indicates whether to GPF because of an invalid MSR access. > > KVM_SET_MSRs should be reserved for MSRs that are performance > sensitive. Not all of them will be. > Right now everything in the vcpu is emulated in the kernel. Everything else is emulated either in the kernel (irqchip) or in userspace. This makes things easier to understand, and is more future friendly if more cpu features become virtualized by hardware. While these are not compelling reasons, they at least lean the balance in favour of a kernel implementation. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.