----- liran.alon@xxxxxxxxxx wrote:
> ----- jmattson@xxxxxxxxxx wrote:
>
> > While we're on the subject, is there any need for L0 to allocate a
> > vpid02 in the common case, where nested EPT is enabled?
> >
> > Per section 28.3.2 of the SDM, volume 3, when EPT is enabled,
> > combined
> > mappings in the TLB are tagged by {VPID, PCID, EP4TA}. With nested
> > EPT, vmcs02 and vmcs01 do not share an EP4TA. Therefore, I think it
> > suffices to simply copy the VPID field from vmcs12 to vmcs02 in
> this
> > case.
>
> Good point. I agree.
> This will trivially allow physical CPU to save multiple TLB entries
> populated by L2 with same EP4TA but different VPIDs.
>
> I do think however that this should be done on a separate patch series
> on top of this one.
> I will check if I can easily create that series of patches.
>
> Thanks,
> -Liran
After some initial investigation, it seems current TLB management in KVM is worse than I thought.
By looking at vmx_set_cr3() (which is the only place which write to VMCS EPT_POINTER),
it seems that every load of a new EPT pointer will vmx_flush_tlb(vcpu, true);
In case of running with enable_ept, this will flush all TLB entries tagged with new loaded EPTP.
This means that on nVMX scenario where vmcs12 uses EPT, the TLB effectively gets flushed
every time you switch between L1 and L2...
In addition, even in non-nVMX scenarios, in the CPU over-commit case, if a physical CPU switches
between running a vCPU of one VM to a vCPU of another VM, it will keep flushing TLB entries of both VMs
even though they are tagged with separate EPTP.
Due to the above, I think I will create a series that will first fix this issue and then perform
the optimization suggested by Jim here.
Regards,
-Liran
