Re: [PATCH] KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled
From: Paolo Bonzini
Date: Sat Jul 25 2026 - 09:33:45 EST
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.
Paolo