From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 9/9] Add VMEXIT handler and intercepts Date: Wed, 03 Sep 2008 12:23:56 +0300 Message-ID: <48BE57AC.3020002@qumranet.com> References: <1220270281-15720-1-git-send-email-agraf@suse.de> <1220270281-15720-2-git-send-email-agraf@suse.de> <1220270281-15720-3-git-send-email-agraf@suse.de> <1220270281-15720-4-git-send-email-agraf@suse.de> <1220270281-15720-5-git-send-email-agraf@suse.de> <1220270281-15720-6-git-send-email-agraf@suse.de> <1220270281-15720-7-git-send-email-agraf@suse.de> <1220270281-15720-8-git-send-email-agraf@suse.de> <1220270281-15720-9-git-send-email-agraf@suse.de> <1220270281-15720-10-git-send-email-agraf@suse.de> <48BBF511.5070803@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, joro@8bytes.org, anthony@codemonkey.ws To: Alexander Graf Return-path: Received: from il.qumranet.com ([212.179.150.194]:43545 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751544AbYICJX6 (ORCPT ); Wed, 3 Sep 2008 05:23:58 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: >>> + svm->vmcb->control.exit_info_2 = svm->vcpu.arch.cr2; >>> >> >> #vmexit isn't supposed to modify cr2, but we've corrupted it here. > > Well, yes and no. We modified the arch.cr2 but later on in vcpu_run we > don't set the vmcb cr2 field based on that when we're running inside a > VM, so cr2 stays the same as before. What about later, when there is a virtual #VMEXIT? Won't that cr2 leak in? >>> + /* Kill any pending exceptions */ >>> + if (svm->vcpu.arch.exception.pending == true) >>> + nsvm_printk("WARNING: Pending Exception\n"); >>> >> >> This should set control.exit_int_info. > > This is more of a fallback. No exceptions should be in "injecting" > state on vmexit. That would mean that after an exit that was not > handled in the nested VMM we need to inject some exception, which > should in almost all cases already raise a #VMEXIT itself. So this > should never hit. What about, say, #PF on the IDT when attempting to inject an exception? We should tell the guest about that so it can reinject the exception into its own guest. -- error compiling committee.c: too many arguments to function