On Mon, 2007-10-01 at 17:23 -0600, Cam Macdonell wrote: > > Actually, I looking into doing a PhD dissertation :) I'm just trying to > get a better working understanding of how kvm (and other VMMs) handle > instructions like int80 that should trap into the OS, but of course in a > VM need to trap into the guest OS (which is running at user-level) and > not the host OS. Do traps by a guest app to the guest OS involve the > VMM at all?
Hi Cam,
The answer has to do with a few different variables:
1) The capabilities of the virtualization technology hw (e.g. VMX, SVM,
etc)
2) The programming of those capabilities by the VMM
The important thing to remember when using VM hardware is: they aren't
*really* executing guest code in "userspace" (though that is a very nice
way to think of them in many respects...I do this myself when its
convenient). They are really executing in a special context
("guest-mode") where the hardware can be programmed in various ways by
the VMM.
Intel VMX for instance, (and AMD-SVM is similar) allows the guest to
have its own Interrupt-Descriptor-Table (IDT) independent of the hosts
IDT. This governs how interrupts are handled when they are injected
into the guest context, just like the host IDT governs how they are
delivered to the VMM. One primary difference, however, is the host has
some programmatic control over the behavior of the guest (within the
constraints of the hardware capabilities, of course). For instance, the
host can program the VMX hardware to cause a VMEXIT when certain
instructions or events happen inside the guest.
VMX has such a control for INTx instructions (see Section 20.6.3 in the
Intel SDM Volume 3b), but (IIUC, and as Anthony mentioned) they are
limited to the first 32 of the 256 vectors in x86 (i.e. the "hardware
exceptions") whereas the remaining vectors are not trappable. What this
means is that if the vector is >= 32, or if its < 32 but the
exit-control is not enabled the INTx instruction will be delivered right
to the guests-IDT without leaving guest-context. Otherwise, it will
VMEXIT back to the host.
IIUC, KVM in particular only sets the control for a handful of the 32
vectors (#PF is one, I'm pretty sure ;). KVM doesn't care about INT80,
and the VMX hardware doesn't support that exit-condition even if it did.
What this means is that on KVM/VMX, an INT80 is delivered to whatever
the guest set up in its own IDT for vector 80, and that's it. The host
wouldn't even know, per se. However, I'm sure there might be some
VMM/HW combo out there other than KVM that might trap INT80, so YMMV.
I hope this helps to clarify.
Good luck on that dissertation!
-Greg
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
