• Nadav Har'El's avatar
    KVM: nVMX: Deciding if L0 or L1 should handle an L2 exit · 644d711a
    Nadav Har'El authored
    This patch contains the logic of whether an L2 exit should be handled by L0
    and then L2 should be resumed, or whether L1 should be run to handle this
    exit (using the nested_vmx_vmexit() function of the previous patch).
    
    The basic idea is to let L1 handle the exit only if it actually asked to
    trap this sort of event. For example, when L2 exits on a change to CR0,
    we check L1's CR0_GUEST_HOST_MASK to see if L1 expressed interest in any
    bit which changed; If it did, we exit to L1. But if it didn't it means that
    it is we (L0) that wished to trap this event, so we handle it ourselves.
    
    The next two patches add additional logic of what to do when an interrupt or
    exception is injected: Does L0 need to do it, should we exit to L1 to do it,
    or should we resume L2 and keep the exception to be injected later.
    
    We keep a new flag, "nested_run_pending", which can override the decision of
    which should run next, L1 or L2. nested_run_pending=1 means that we *must* run
    L2 next, not L1. This is necessary in particular when L1 did a VMLAUNCH of L2
    and therefore expects L2 to be run (and perhaps be injected with an event it
    specified, etc.). Nested_run_pending is especially intended to avoid switching
    to L1 in the injection decision-point described above.
    Signed-off-by: default avatarNadav Har'El <nyh@il.ibm.com>
    Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
    644d711a
vmx.c 196 KB