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
--
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
