[Bug 54161] New: nVMX: nested vpid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.kernel.org/show_bug.cgi?id=54161

           Summary: nVMX: nested vpid
           Product: Virtualization
           Version: unspecified
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: kvm
        AssignedTo: virtualization_kvm@xxxxxxxxxxxxxxxxxxxx
        ReportedBy: nyh@xxxxxxxxxxxxxxxxxxx
        Regression: No


Currently, support for VPID in nested VMX is minimal: L1 doesn't see the vpid
feature, and doesn't use it, but L0 may use it (if available) when running the
guests: We use the same vpid to run L1 and all its L2 guests, but             
vmx_flush_tlb(vcpu) when going back and forth between L1 and L2 - this flushes
this particular vpid, but at least leave other L1's cache entries behind.

A better performing solution would be to support "nested vpid" - L0 exposes to
L1 the VPID feature, and maintains a mapping between VPID numbers that L1 uses
to VPID numbers that it uses. L0 runs each of its guests - L1s and L2s, as
separate guests.

Some points to remember while doing this (this is only a partial list!):

1. Remember to set vmx->vpid on nested_vmx_run() and nested_vmx_vmexit() to
L1's and L2's vpid. This is important because vmx_flush_tlb() (called on
context switch between a guest's processes) flushes only the current vpid (if
possible) and we need to do it to the correct one.
2. In free_nested(), also free the vpids that have been allocated to all the
L2s. This can probably be done in nested_free_saved_vmcs() (see mention above).
However, note that free_nested() is preceded (in vmx_free_vcpu()) by a call to
free_vpid() which frees the current vmx->vpid, which might be l1 or l2 and we
need to make sure we free all of them, and just once.
3. Implement, of course, also INVVPID for L1.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux