Traditional x86 architecture implicitly requires TLB flushing upon context switching (CR3 writes) so the new process-to-run's address space does not conflict with lineal to physical translations cached by previous processes. When using shadow pages for MMU virtualization, it can be quite expensive to throw away.
Intel introduced Virtual Processor ID (vpid) into its VT-x technology in order to tag different processes and therefore avoid unnecessary TLB flushes.
KVM uses a global bitmap to facilitate vpid management for all guests and all vCPUs, managing up to ~64000 unique identifiers. Upon virtual machine startup it will allocate a vpid for each vCPU with a first-come, first-serve policy. The data is protected by a vmx_vpid_lock spinlock.
CODE
static DECLARE_BITMAP(vmx_vpid_bitmap, VMX_NR_VPIDS);
static DEFINE_SPINLOCK(vmx_vpid_lock);
...
static void allocate_vpid(struct vcpu_vmx *vmx)
{
int vpid;
vmx->vpid = 0;
if (!enable_vpid)
return;
spin_lock(&vmx_vpid_lock);
vpid = find_first_zero_bit(vmx_vpid_bitmap, VMX_NR_VPIDS);
if (vpid < VMX_NR_VPIDS) {
vmx->vpid = vpid;
__set_bit(vpid, vmx_vpid_bitmap);
}
spin_unlock(&vmx_vpid_lock);
}
Similarly, when the guest is shutdown, it will free its corresponding the vpid(s):
CODE
static void free_vpid(struct vcpu_vmx *vmx)
{
if (!enable_vpid)
return;
spin_lock(&vmx_vpid_lock);
if (vmx->vpid != 0)
__clear_bit(vmx->vpid, vmx_vpid_bitmap);
spin_unlock(&vmx_vpid_lock);
}
To invalidate different cached translations based on vpid, Intel added the invvpid instruction. The specific invalidations are grouped as (for more information check the Intel reference manual vol. 3C 2.8 - Caching Translation Information):
- Individual address: the vCPU invalidates translations for a specific given address and PID
- Single context: the vCPU invalidates all tagged translations for a specific given VPID
- All context: the vCPU invalidates all translations for all VPIDs (except the original, id 0)
- Single context, retaining global translations: the vCPU invalidates all tagged translations for a specific given VPID, except global translations.
Whenever there's a TLB flush call or a vCPU reset (like when setting up the architecture at boot time), both part of standard x86 operations, the vpid_sync_context() function is called:
static inline void vpid_sync_context(struct vcpu_vmx *vmx)
{
if (cpu_has_vmx_invvpid_single())
vpid_sync_vcpu_single(vmx);
else
vpid_sync_vcpu_global();
}
This function calls the corresponding invalidation type, previously described. The
vpid_sync_vcpu_single() routine obviously must pass the vmx->vpid in order to specify what id its referring to.
Both global and single contexts end up calling __invvpid(), that does all assembler the work.
The VPID feature can be enabled/disabled by traditional kernel module parameters at /sys/module/kvm_intel/parameters/vpid
A while ago I proposed a patch to enable tracing vpid management for simulating tagged TLB behavior and performance. Unfortunately tracing these events for experimentation/research did not suit mainstream enough to be officially merged. Understandable.
Vollständiger Original-Bericht
Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf blog.stgolabs.net.
SOCIAL SHARE CARD GENERATOR