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:47:55 +0300 Message-ID: <48BE5D4B.4050509@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> <48BE57AC.3020002@qumranet.com> <520347F2-D392-44B2-8A4E-0A1F61365A76@suse.de> 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]:49005 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686AbYICJr5 (ORCPT ); Wed, 3 Sep 2008 05:47:57 -0400 In-Reply-To: <520347F2-D392-44B2-8A4E-0A1F61365A76@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: > > On Sep 3, 2008, at 11:23 AM, Avi Kivity wrote: > >> 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? > > The cr2 value would leak into the level1 guest that can't rely on CR2 > to be correct anyways. That's not very nice. > >> >> >>>>> + /* 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. > > Doesn't the CPU already does this for us? When the guest VMM wants to > inject an interrupt/exception, that would result in a real injection. It could be an exception initiated by the CPU (say, divide overflow) or an exception initiated by the guest VMM. > So when we get a #PF on the IDT the real CPU already filled > exit_int_info for us and we can just pass it on to the guest VMM... > We might be emulating a nested guest instruction, and injecting some expection. > I can't think of a situation where we inject a #PF and did not get a > #VMEXIT from a #PF before that. I'm confused... -- error compiling committee.c: too many arguments to function