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

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

[Paolo Bonzini]

Linus,

The following changes since commit 848acc8ffe1b7cd5f1bf427b93069becfebc2c9d:

  Merge tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux (2026-08-03 12:26:51 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to 5ec42d57655c690234c14aece6dd3f209778c1d8:

  KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page (2026-08-07 09:26:45 +0200)

----------------------------------------------------------------
s390:
- fix a lot of small bugs and races

x86:
- fix missing locking related to KVM_CAP_MOVE_ENC_CONTEXT_FROM

- warn on creating a new page table that is the child of an invalid one,
  and limit damage before it's too late

- disable use of INVLPGA when NPT is enabled, because it doesn't seem
  to flush TLBs correctly

----------------------------------------------------------------
Claudio Imbrenda (13):
      KVM: s390: Fix unlikely NULL gmap dereference
      KVM: s390: Do not free SCA if it was not allocated
      KVM: s390: Fix kvm_s390_vcpu_unsetup_cmma()
      KVM: s390: Fix overclearing ESCA in case of error
      KVM: s390: ucontrol: Fix sca_clear_ext_call()
      KVM: s390: Fix leaking of PGM_ADDRESSING to userspace
      KVM: s390: Fix race in __do_essa()
      KVM: s390: cmma: Fix dirty tracking when removing memslot
      KVM: s390: ucontrol: Add missing locking around gmap_remove_child()
      KVM: s390: Free the mmu cache when kvm_arch_vcpu_create() fails
      KVM: s390: Return -EINTR if a signal is pending while faulting-in
      KVM: s390: Fix ordering when adding to SCA
      KVM: s390: Fix cleanup in kvm_s390_pv_create_cpu()

Eric Farman (10):
      s390/vfio_ccw: Free all memory if cp_init() fails
      s390/vfio_ccw: Limit the number of channel program segments
      s390/vfio_ccw: Fix out of bounds check on CCW array
      s390/vfio_ccw: Ensure first IDAW remains constant
      s390/vfio_ccw: Calculate idal length based on idaw type
      s390/vfio_ccw: Ensure index for read/write regions are within range
      s390/vfio_ccw: Cancel existing workqueues
      s390/vfio_ccw: Move cp cleanup out of not operational
      s390/vfio_ccw: Selectively expand io_mutex
      s390/vfio_ccw: Implement a crw lock

Paolo Bonzini (3):
      KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled
      Merge tag 'kvm-s390-master-7.2-3' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD
      KVM: SVM: Serialize accesses to the owner and mirror list with separate lock

Sean Christopherson (1):
      KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page

 arch/s390/include/asm/kvm_host.h    |   1 +
 arch/s390/kvm/dat.c                 |  23 +++++--
 arch/s390/kvm/dat.h                 |   2 +-
 arch/s390/kvm/faultin.c             |   6 +-
 arch/s390/kvm/interrupt.c           |  19 ++++--
 arch/s390/kvm/kvm-s390.c            | 125 +++++++++++++++++++++++-------------
 arch/s390/kvm/priv.c                |  10 +--
 arch/s390/kvm/pv.c                  |  43 +++++++------
 arch/x86/include/asm/kvm_host.h     |   2 +-
 arch/x86/kvm/hyperv.c               |   7 +-
 arch/x86/kvm/mmu/mmu.c              |   5 +-
 arch/x86/kvm/svm/sev.c              |  34 +++++++---
 arch/x86/kvm/svm/svm.c              |  27 ++++++--
 arch/x86/kvm/svm/svm.h              |   1 +
 arch/x86/kvm/vmx/main.c             |   4 +-
 arch/x86/kvm/vmx/vmx.c              |   2 +-
 arch/x86/kvm/vmx/x86_ops.h          |   2 +-
 drivers/s390/cio/vfio_ccw_async.c   |  16 +++++
 drivers/s390/cio/vfio_ccw_chp.c     |  31 +++++++--
 drivers/s390/cio/vfio_ccw_cp.c      |  74 +++++++++++++++------
 drivers/s390/cio/vfio_ccw_cp.h      |  10 +++
 drivers/s390/cio/vfio_ccw_drv.c     |  21 +++++-
 drivers/s390/cio/vfio_ccw_fsm.c     |   8 ++-
 drivers/s390/cio/vfio_ccw_ops.c     |  39 +++++++++--
 drivers/s390/cio/vfio_ccw_private.h |  10 ++-
 25 files changed, 379 insertions(+), 143 deletions(-)

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

[pr-tracker-bot]

The pull request you sent on Fri,  7 Aug 2026 15:53:27 +0200:

> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0150da6be1c71cd0ad9262293971cb9ea371672b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

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

[Sean Christopherson]

+Yosry

On Fri, Aug 07, 2026, Paolo Bonzini wrote:
> - disable use of INVLPGA when NPT is enabled, because it doesn't seem
>   to flush TLBs correctly

...

> Paolo Bonzini (3):
>       KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled

Why did this get rushed in?  There was quite a bit of discussion, both on the
code itself[1][2] and on the assessment that this appears to be hardware issue[3].
IMO, neither of those discussions was resolved enough to merge the patch as-is.

I can appreciate wanting to get a fix into stable ASAP, but we could have gone
with a *much* simpler fix for stable@.  The bulk of this change is a performance
optimization masquerading as a bug fix, and I'm not convinced it's actually
optimizing anything meaningful, because SVM only queues the TLB flush, and that
is super cheap.  E.g. the "we don't know why this is failing, let's smack it with
a hammer" patch could have been:

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 3057ca7051db..58bc4a1cb7a4 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4237,7 +4237,15 @@ static void svm_flush_tlb_gva(struct kvm_vcpu *vcpu, gva_t gva)
 {
        struct vcpu_svm *svm = to_svm(vcpu);
 
-       invlpga(gva, svm->vmcb->control.asid);
+       if (!npt_enabled) {
+               invlpga(gva, svm->vmcb->control.asid);
+               return;
+       }
+
+       if (static_cpu_has(X86_FEATURE_FLUSHBYASID))
+               svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ASID;
+       else
+               svm->current_vmcb->asid_generation--;
 }
 
 static void svm_flush_tlb_guest(struct kvm_vcpu *vcpu)

I don't care _that_ much about the code itself, though I still think the out-param
is all kinds of ugly.  What frustrates me most is completely ignoring the processes
that everyone else is trying quite hard to follow.  I'm a-ok with getting overruled
on jugdment calls and matters of taste, but I'm not at all ok with doing so silently
and without what I would consider an honest attempt to address review feedback.

[1] https://lore.kernel.org/all/amPo-XdhFGIZquES@google.com
[2] https://lore.kernel.org/all/CAO9r8zM=Mb=eTEFGF0G-POvwwbSr7e8SN6zcDp=GstzKtBKcow@mail.gmail.com
[3] https://lore.kernel.org/all/CAO9r8zMopB=YKXs5pkQmPf9uHKE0P0XORcNbc60AWXTusuY3tg@mail.gmail.com

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

[Paolo Bonzini]

Il ven 7 ago 2026, 19:07 Sean Christopherson <seanjc@google.com> ha scritto:
> On Fri, Aug 07, 2026, Paolo Bonzini wrote:
> > - disable use of INVLPGA when NPT is enabled, because it doesn't seem
> >   to flush TLBs correctly
> >
> > Paolo Bonzini (3):
> >       KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled
>
> Why did this get rushed in?

I waited two weeks with the patch on the mailing list. It didn't (and
doesn't) seem like rushing in?

>   There was quite a bit of discussion, both on the
> code itself[1][2] and on the assessment that this appears to be hardware issue[3].
> IMO, neither of those discussions was resolved enough to merge the patch as-is.
>
> I can appreciate wanting to get a fix into stable ASAP, but we could have gone
> with a *much* simpler fix for stable@.  The bulk of this change is a performance
> optimization masquerading as a bug fix, and I'm not convinced it's actually
> optimizing anything meaningful, because SVM only queues the TLB flush, and that
> is super cheap.  E.g. the "we don't know why this is failing, let's smack it with
> a hammer" patch could have been:

It is true that the patch below is smaller and pretty much the same
for all practical purposes. I don't even think it's a matter for
stable vs. mainline, the patch is totally fine in both; maybe with a
comment about the performance being totally fine, since that is
different on Intel vs. AMD, but that's it.

> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 3057ca7051db..58bc4a1cb7a4 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -4237,7 +4237,15 @@ static void svm_flush_tlb_gva(struct kvm_vcpu *vcpu, gva_t gva)
>  {
>         struct vcpu_svm *svm = to_svm(vcpu);
>
> -       invlpga(gva, svm->vmcb->control.asid);
> +       if (!npt_enabled) {
> +               invlpga(gva, svm->vmcb->control.asid);
> +               return;
> +       }
> +
> +       if (static_cpu_has(X86_FEATURE_FLUSHBYASID))
> +               svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ASID;
> +       else
> +               svm->current_vmcb->asid_generation--;
>  }
>
>  static void svm_flush_tlb_guest(struct kvm_vcpu *vcpu)
>
> I don't care _that_ much about the code itself, though I still think the out-param
> is all kinds of ugly. I'm not at all ok with doing so silently
>
> and without what I would consider an honest attempt to address review feedback.

Sorry about that, but again - I waited two weeks and got no reply to
https://lore.kernel.org/all/CABgObfbDE+=ir_phPC+9sVYnNXur6dFx6oAfEGSnCbrOqFoyVA@mail.gmail.com/.
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).

If you had proposed the above small patch, for example, it would have
been a completely different thing. I would have taken your suggestion
immediately.

Paolo

>
> [1] https://lore.kernel.org/all/amPo-XdhFGIZquES@google.com
> [2] https://lore.kernel.org/all/CAO9r8zM=Mb=eTEFGF0G-POvwwbSr7e8SN6zcDp=GstzKtBKcow@mail.gmail.com
> [3] https://lore.kernel.org/all/CAO9r8zMopB=YKXs5pkQmPf9uHKE0P0XORcNbc60AWXTusuY3tg@mail.gmail.com
>

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

[Sean Christopherson]

On Fri, Aug 07, 2026, Paolo Bonzini wrote:
> Il ven 7 ago 2026, 19:07 Sean Christopherson <seanjc@google.com> ha scritto:
> > On Fri, Aug 07, 2026, Paolo Bonzini wrote:
> > I don't care _that_ much about the code itself, though I still think the out-param
> > is all kinds of ugly. I'm not at all ok with doing so silently
> >
> > and without what I would consider an honest attempt to address review feedback.
> 
> Sorry about that, but again - I waited two weeks and got no reply to
> https://lore.kernel.org/all/CABgObfbDE+=ir_phPC+9sVYnNXur6dFx6oAfEGSnCbrOqFoyVA@mail.gmail.com/.
> 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

I also didn't prioritize responding (or even digging deeper) because I wasn't
expecting the patch to get fast-tracked to 7.2.  It's not tagged for stable, the
code has existed for years, and at least for me, nothing else suggested it needed
to go in *now*.  It doesn't help that the commit showed up in kvm/master late
yesterday; the first heads up I got that you were applying the patch as-is was
this pull request.

In other words, it's the lack of communication that's frustrating.  Even a simple
"Hey, I'm applying this unless someone screams" would have sufficed.

> If you had proposed the above small patch, for example, it would have
> been a completely different thing. 

Heh, if only past me had realized we could have done that.  I guess the desire to
prove someone "wrong" on the internet is the mother of all invention? :-D

> I would have taken your suggestion immediately.
> 
> Paolo
> 
> >
> > [1] https://lore.kernel.org/all/amPo-XdhFGIZquES@google.com
> > [2] https://lore.kernel.org/all/CAO9r8zM=Mb=eTEFGF0G-POvwwbSr7e8SN6zcDp=GstzKtBKcow@mail.gmail.com
> > [3] https://lore.kernel.org/all/CAO9r8zMopB=YKXs5pkQmPf9uHKE0P0XORcNbc60AWXTusuY3tg@mail.gmail.com
> >
>