On Sep 3, 2008, at 11:47 AM, Avi Kivity wrote:
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.
Is it a problem? We could set arch.cr2 to nested_vmcb->save.cr2 on
#VMEXIT, so the emulated #VMEXIT behaves the same way as real hardware
(just let the CR2 value from the guest slip through).
+ /* 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...
The only cases we override a #VMEXIT to be taken by the host KVM
instead of the nested VMM are:
- INTR
- NMI
- NPF
- PF
Intr and NMI are nops.
NPF handles only the nested page faults and should not inject anything
or emulate any instructions. It's basically invisible from within the
VM.
PF comes into the game when handling double-shadow-pages. Here we
might need to emulate an instruction or inject a #PF into the guest.
Since we already left the VM due to a #PF, exit_int_info is already
set correctly and will just be copied to the nested vmcb, so we don't
need to handle that case, no?
All other exits result in a direct #VMEXIT that keep all control
information for the guest VMM.
Alex
--
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
