From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] [2/2] KVM: Add VT-x machine check support Date: Thu, 04 Jun 2009 15:49:03 +0300 Message-ID: <4A27C2BF.3090108@redhat.com> References: <20090604112.650907584@firstfloor.org> <20090604111205.C47C31D0282@basil.firstfloor.org> <4A27B481.5020003@redhat.com> <20090604125123.GY1065@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ying.huang@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org To: Andi Kleen Return-path: Received: from mx2.redhat.com ([66.187.237.31]:37756 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755673AbZFDMtJ (ORCPT ); Thu, 4 Jun 2009 08:49:09 -0400 In-Reply-To: <20090604125123.GY1065@one.firstfloor.org> Sender: kvm-owner@vger.kernel.org List-ID: Andi Kleen wrote: >> This assumption is incorrect. This code is executed after preemption >> has been enabled, and we may have even slept before reaching it. >> > > The only thing that counts here is the context before the machine > check event. If there was a vmexit we know it was in guest context. > > The only requirement we have is that we're running still on the same > CPU. I assume that's true, otherwise the vmcb accesses wouldn't work? > It's not true, we're in preemptible context and may have even slept. vmcs access work because we have a preempt notifier called when we are scheduled in, and will execute vmclear/vmptrld as necessary. Look at kvm_preempt_ops in virt/kvm_main.c. >> We get both an explicit EXIT_REASON and an exception? >> > > These are different cases. The exception is #MC in guest context, > the EXIT_REASON is when a #MC happens while the CPU is executing > the VM entry microcode. > I see, thanks. -- error compiling committee.c: too many arguments to function