From: sashiko-bot@kernel.org
To: "Christian Borntraeger" <borntraeger@linux.ibm.com>
Cc: KVM <kvm@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [GIT PULL 1/6] KVM: s390: fix ESSA addressing exception injection in migration mode
Date: Fri, 06 Nov 2026 17:34:09 +0000 [thread overview]
Message-ID: <sashiko-outbox-201943@kernel.org> (raw)
In-Reply-To: <20261106164958.431978-2-borntraeger@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] KVM: s390: commit message states -PGM_ADDRESSING instead of
PGM_ADDRESSING
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [High] KVM: s390: missing CMMA init and page table allocation in
handle_essa() [1]
--
commit ee014980cbe371ebff00ee828f1f5961b34040ff
Author: Gautam Gala <ggala@linux.ibm.com>
KVM: s390: fix ESSA addressing exception injection in migration mode
This commit updates dat_perform_essa() to pass DAT_WALK_ANY to
dat_entry_walk() and return PGM_ADDRESSING on walk failure, so __do_essa()
injects an addressing exception instead of silently dropping it.
> Return -PGM_ADDRESSING on a walk failure and inject the program
> interrupt in __do_essa() for the -PGM_ADDRESSING return value.
[Severity: Low]
This isn't a bug, but the commit message says -PGM_ADDRESSING whereas the
code returns and checks positive PGM_ADDRESSING.
> diff --git a/arch/s390/kvm/s390/priv.c b/arch/s390/kvm/s390/priv.c
> index 856939acf012f..b252c812dcbe7 100644
> --- a/arch/s390/kvm/s390/priv.c
> +++ b/arch/s390/kvm/s390/priv.c
> @@ -1169,6 +1169,8 @@ static inline int __do_essa(struct kvm_vcpu *vcpu, const int orc)
> entries = (vcpu->arch.sie_block->cbrlo & ~PAGE_MASK) >> 3;
>
> nappended = dat_perform_essa(vcpu->arch.gmap->asce, gfn, orc, &state, &dirtied);
> + if (nappended == PGM_ADDRESSING)
> + return kvm_s390_inject_program_int(vcpu, PGM_ADDRESSING);
> vcpu->run->s.regs.gprs[r1] = state.val;
> if (nappended < 0)
> return 0;
[Severity: High]
This problem wasn't introduced by this patch, but can an initial ESSA
intercept arriving after migration has already started reach __do_essa()
without GMAP_FLAG_USES_CMM set or guest page tables allocated [1]?
In handle_essa(), setting GMAP_FLAG_USES_CMM and calling
gmap_allocate_all_page_tables_best_effort() only happen in the
!migration_mode branch:
arch/s390/kvm/s390/priv.c:handle_essa() {
...
if (!READ_ONCE(vcpu->kvm->arch.migration_mode)) {
...
if (!uses_cmm(vcpu->arch.gmap)) {
set_bit(GMAP_FLAG_USES_CMM, &vcpu->arch.gmap->flags);
gmap_allocate_all_page_tables_best_effort(vcpu->arch.gmap);
}
...
} else {
scoped_guard(mutex, &vcpu->kvm->slots_arch_lock)
scoped_guard(read_lock, &vcpu->kvm->mmu_lock)
i = __do_essa(vcpu, orc);
...
}
If the guest executes its first ESSA instruction while migration_mode is
already active, dat_perform_essa() walks the gmap without allocating missing
page tables, returning an exception state and dropping the PGSTE update for
any unallocated segment. In addition, because GMAP_FLAG_USES_CMM remains
unset on kvm->arch.gmap, kvm_s390_get_cmma_bits() sees
!uses_cmm(kvm->arch.gmap) and returns zeroed data, losing dirtied guest CMMA
attributes during live migration.
[1] https://sashiko.dev/#/bug/linux-20a07467-1a8a-41bb-8117-0f046fed9112
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106164958.431978-2-borntraeger@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-11-06 17:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 16:49 [GIT PULL 0/6] KVM: s390: Fixes for 7.4 Christian Borntraeger
2026-11-06 16:49 ` [GIT PULL 1/6] KVM: s390: fix ESSA addressing exception injection in migration mode Christian Borntraeger
2026-11-06 17:34 ` sashiko-bot [this message]
2026-11-06 16:49 ` [GIT PULL 2/6] KVM: s390: pqap: fix AP status written to wrong half of GR1 Christian Borntraeger
2026-11-06 16:54 ` sashiko-bot
2026-11-06 16:49 ` [GIT PULL 3/6] KVM: s390: arm64: Turn vcpu->arch.pause into a counter Christian Borntraeger
2026-11-06 16:55 ` sashiko-bot
2026-11-06 16:49 ` [GIT PULL 4/6] KVM: s390: arm64: Declare enum vcpu_sysreg Christian Borntraeger
2026-11-06 16:59 ` sashiko-bot
2026-11-06 16:49 ` [GIT PULL 5/6] KVM: s390: arm64: Fix kvm_arm64 module naming consistency Christian Borntraeger
2026-11-06 16:59 ` sashiko-bot
2026-11-06 16:49 ` [GIT PULL 6/6] selftests: drivers/s390x: Select uvdevice tests using the target architecture Christian Borntraeger
2026-11-06 16:56 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-201943@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.