Re: [PATCH] KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled

[Yosry Ahmed]

On Sat, Jul 25, 2026 at 6:32 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> Il sab 25 lug 2026, 01:44 Yosry Ahmed <yosry@xxxxxxxxxx> ha scritto:
> > > +       /*
> > > +        * INVLPGA has had errata on Genoa and Turin, and even on older
> > > +        * generations there were reports of Windows BSODs if INVLPGA
> > > +        * was used for Hyper-V tlbflush.  Use it only for shadow paging
> > > +        * where it seems to be okay.
> >
> > Is this an actual errata documented by AMD, or is this just an
> > empirical observation?
>
> There is the VMware knowledge base in the commit message that requires
> new microcode:
>
> > > For Turin, the microcode version was 0x0b002162, which (assuming
> > > this is the same issue) should not be affected by the problem listed in
> > > https://knowledge.broadcom.com/external/article/419026/bsod-on-virtual-machines-running-on-amd.html;
> > > on the other hand that problem should not apply to earlier processors.
> > > AMD has not provided any information or analysis yet, and when we asked
> > > we didn't know yet that it reproduced on Milan as well.
>
> and I interpreted that as an erratum. But we reproduced it also on
> Milan and with supposedly fixed microcode.
>
> > I ask because the APM says:
> > ---
> > The input address is always interpreted as a guest virtual address, so
> > INVLPGA is typically meaningful only when used with shadow page
> > tables; it does not provide a means to invalidate a nested translation
> > by guest physical address
> > ---
> >
> > While this is terrible wording, it seems like KVM should *not* be
> > using INVLPGA when TDP is enabled
>
> While it is certainly an odd case, here the guest has requested to do
> an invalidation by GVA on its behalf, so INVLPGA should have worked.
>
> "Not typically meaningful" is a friendly hint to read the manual
> twice, but reality seems to be more like "doesn't actually flush the
> right entries" when NPT is in use. Especially since Intel has INVVPID
> for the exact same operation and it works just fine.

Yeah I agree that it makes sense that INVLPGA should work if we are
just flushing a GVA on behalf of the guest (e.g. guest making a
hypercall instead of INVLPG).

I think we probably need clarification from AMD about what the
intention is. Is INVLPGA expected to be broken when NPT is enabled (in
which case the wording in the APM needs fixing), or is INVLPGA
expected to work but is actually broken. IIUC the erratum you referred
to should already be fixed with the new microcode, so maybe there's
another problem with INVLPGA?

The third possibility is that INVLPGA works as intended but the
Hyper-V code in KVM is broken in some other way. I am not sure if we
can ask, or if people at Microsoft can answer, but it would definitely
help to know how Hyper-V handles these cases. Does it actually use
INVLPGA to flush GVAs on behalf of the guest with NPT enabeld? If yes,
there's a good chance it's KVM that's broken here?