On Tue, 2018-05-22 at 08:50 -0700, Jim Mattson 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.
VPID handling in general looks like it could use a good once-over,
e.g. vpid02 allocation can be delayed until prepare_vmcs02_full(),
we never re-attempt VPID allocation in the (extremely unlikely)
case that there are no available VPIDs at vmx_create_vcpu(), and
load_vmcs12_host_state() explicitly flushes the TLB when VPID is
enabled because it has obsolete code that assumes L1 and L2 always
share a VPID.
> On Tue, May 22, 2018 at 7:16 AM, Liran Alon <liran.alon@xxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > This series aims to optimize KVM nested-VPID implementation.
> > Note: All the patches in this series are indepdendent and can be
> > applied seperately.
> >
> > 1st patch is just a small refactoring change.
> >
> > 2nd patch fixes a corner-case of not failing INVVPID type 0
> > (individiual-address) in case operand.vpid==0.
> >
> > 3rd patch fixes an ancient issue of unnecessarely flushing TLB when
> > exiting from L2 to L1 even though TLB entries populated by L2 are
> > tagged with different VPID (vmx->nested.vpid02) than TLB entries
> > populated by L1 (vmx->vpid).
> >
> > 4rd patch optimizes L1 INVVPID type 0 (individiual-address) handling
> > by emulating it with INVVPID type 0 executed at L0 level. This allows
> > flushing only a single TLB entry tagged with vmx->nested.vpid02
> > instead of all TLB entries tagged with vmx->nested.vpid02.
> >
> > Regards,
> > -Liran Alon
