Re: [GIT PULL] KVM (mostly s390) fixes for Linux 7.2-rc7

On Fri, Aug 7, 2026 at 10:43 PM Paolo Bonzini <[email protected]> wrote:
>
> Il sab 8 ago 2026, 00:39 Sean Christopherson <[email protected]> ha scritto:
> > On Fri, Aug 07, 2026, Paolo Bonzini wrote:
> > > I consider two weeks of wait, on a review that so far had been
> > > exclusively about taste, to *be* an honest attempt to gather the next
> > > round of feedback (which never came).
> >
> > Heh, and I was waiting for a response to Yosry's thread:
> > https://lore.kernel.org/all/CAO9r8zODKgCcjTBK=P6BuXBBZRoOAFMeRJU8BmkWL-BCX2LoBw@mail.gmail.com
>
> Heh^2, "Pick your poison, I guess" was not really inviting a response.
> Overall the sense of my reply to you (that is: there are two callers
> so let's not overthink wrappers) applied just as much to his message;
> and checking AMD vs. Intel in common code is a total no-no so I kept
> the reply in one place.

Aside from the code itself, I was really hoping for a better
understanding of the problem, and answers from AMD/Hyper-V folks if
possible.

Basically:

(a) Is INVLPGA intended to be used with NPT enabled to flush GVA
translations on behalf of the guest?

I assume the answer is yes, and something is broken. But if the answer
is no, then we shouldn't be looking any further and the fix proposed
by you/Sean is correct regardless.

(b) Does Hyper-V use INVLPGA with NPT enabled to serve similar
paravirt TLB flushes?

If the answer is yes, I think it's likely there's a KVM bug and not a
hardware bug, as I assume the issue would have been caught on Windows
sooner. I don't know if we can realistically get an answer to this
from Hyper-V folks or who to ask, but I think an answer would help.

My goal is to make sure we are not papering over an existing bug in
KVM's Hyper-V code. The fact that hyperv_tlb_flush is flaky with NPT=0
makes me suspect there's a bug somewhere in this code, and it might be
manifesting differently for NPT=0/1.