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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
