Re: [PATCH v1 25/28] KVM: nSVM: Flush L2's ASID when emulating INVLPGA

On Mon, Aug 03, 2026, Yosry Ahmed wrote:
> On Fri, Jul 31, 2026 at 11:41=E2=80=AFPM Yosry Ahmed <[email protected]> w=
rote:
> >
> > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > > index e4bda43238654..d7b20941b1fee 100644
> > > --- a/arch/x86/kvm/svm/svm.c
> > > +++ b/arch/x86/kvm/svm/svm.c
> > > @@ -2425,17 +2425,51 @@ static int clgi_interception(struct kvm_vcpu =
*vcpu)
> > >
> > >  static int invlpga_interception(struct kvm_vcpu *vcpu)
> > >  {
> > > +       struct vcpu_svm *svm =3D to_svm(vcpu);
> > >         /* FIXME: Handle an address size prefix. */
> > >         gva_t gva =3D kvm_rax_read(vcpu);
> > >         u32 asid =3D kvm_ecx_read(vcpu);
> > > +       int cpu;
> > >
> > >         if (nested_svm_check_permissions(vcpu))
> > >                 return 1;
> > >
> > >         trace_kvm_invlpga(to_svm(vcpu)->vmcb->save.rip, asid, gva);
> > >
> > > -       /* Let's treat INVLPGA the same as INVLPG (can be optimized!)=
 */
> > > -       kvm_mmu_invlpg(vcpu, gva);
> > > +       /*
> > > +        * INVLPG on a non-canonical address is a NOP according to th=
e SDM,
> > > +        * assumethe same behavior from INVLPGA since the APM doesn't=
 specify.
> > > +        */
> > > +       if (is_noncanonical_invlpg_address(gva, vcpu))
> > > +               return kvm_skip_emulated_instruction(vcpu);
> >
> > From internal Sashiko:
> > ---
> > This is a pre-existing issue and was not introduced by the patch under =
review,
> > but if L1 is configured for 4-level paging and L2 is configured for 5-l=
evel
> > paging, could this drop valid INVLPGA TLB flushes for L2?
> >
> > Since vcpu represents L1, the check is_noncanonical_invlpg_address(gva,=
 vcpu)
> > uses L1's canonical boundaries. If L1 executes INVLPGA to flush a valid=
 57-bit
> > virtual address for the L2 guest, will KVM incorrectly deem the L2 addr=
ess as
> > non-canonical and silently skip emulation?
> >
> > Bypassing both the hardware TLB flush and shadow page table synchroniza=
tion
> > could allow L2 to continue accessing memory through old translations,
> > potentially leading to memory corruption or security boundary bypass
> > inside L2.
> > ---
> >
> > I need to take a closer look here, but if this is indeed an issue,
> > even if pre-existing, it would only matter with this series. Before
> > this series, even if INVLPGA is ignored we flush everything before
> > running L2 anyway.
>=20
> I don't think this is an issue. is_noncanonical_invlpg_address()
> doesn't use "L1's canonical boundaries". It calls
> is_noncanonical_address(.., X86EMUL_F_INVLPG), which calls
> __is_canonical_address(.., max_host_virt_addr_bits()). So the
> canonicality checks depend on the host support, not L1's CPUID or
> configuration.

Yep, this is a complete non-issue.

> The only potentially interesting case is if hardware
> only supports 48-bit addresses and L1 decides to emulate 57-bit
> addresses (e.g. emulate 5-level paging on HW with only 4-level paging
> support). In this case (if it all possible to begin with), I assume
> it's L1's responsibility to make sure this is emulated correctly (e.g.
> intercept L2's page faults with higher bits set).

Yep.