From: Marc Zyngier <maz@kernel.org>
To: Sebastian Ott <sebott@redhat.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
Quentin Perret <qperret@google.com>,
Fuad Tabba <tabba@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: LM regression: fce886a60207 KVM: arm64: Plumb the pKVM MMU in KVM
Date: Mon, 05 May 2025 12:34:29 +0100 [thread overview]
Message-ID: <86msbrguka.wl-maz@kernel.org> (raw)
In-Reply-To: <3f5db4c7-ccce-fb95-595c-692fa7aad227@redhat.com>
On Mon, 05 May 2025 11:52:00 +0100,
Sebastian Ott <sebott@redhat.com> wrote:
>
> Hey,
>
> Doing back and forth migrations currently fails on arm after a couple iterations.
> During the failing migration KVM_RUN exits via guest_abort and returns -ENOMEM.
> I can reliably reproduce this by migrating between 2 qemu instances on an ampere
> altra machine. This fails after < 5 iterations. In this case qemu would spit out
> smth like this (other than that - nothing in the logs):
>
> error: kvm run failed Cannot allocate memory
> PC=0000aaaae7d48590 X00=0000aaaae80a2e00 X01=0000aaaae7ea2fc0
> X02=0000000001d3a5d0 X03=0000aaaae7eace8c X04=000000003b9aca00
> X05=000000000000004a X06=000000000000004a X07=0000000028000000
> X08=0000000000001d70 X09=0000000000000018 X10=000144b7d0000000
> X11=00ffffffffffffff X12=000000008378f367 X13=0000aaab1a202d70
> X14=0000000000000000 X15=0000000000000000 X16=0000ffffa2e2f7a8
> X17=0000ffffa2541f20 X18=000000000000a000 X19=84bfda6288cf2dd6
> X20=0000aaab1a1f1ce0 X21=000000007fffffff X22=0000ffffc5431788
> X23=0000aaab1a17db60 X24=0000ffffc5431770 X25=0000000100000000
> X26=0000004100000000 X27=0000000000000001 X28=0000aaab1a1f1c20
> X29=0000ffffc54316d0 X30=0000aaaae7f8cd24 SP=0000ffffc5431650
> PSTATE=20001000 --C- EL0t
>
> Guest and host are otherwise idle, kvm is in normal VHE mode.
>
> Git bisect points to (fce886a60207 "KVM: arm64: Plumb the pKVM MMU in KVM")
> I also double checked that by reverting this commit on top of 6.14.
Thanks for find the triggering commit. Can you further identify *what*
causes the -ENOMEM? The only new -ENOMEM in that patch is the one
added to topup_hyp_memcache(), which shouldn't be called.
Also, a failure to allocate would leave some nastygram in the kernel
log, so it is unlikely to be an actual failure to allocate.
Is it the first KVM_RUN that fails after migration?
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-05-05 11:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-05 10:52 LM regression: fce886a60207 KVM: arm64: Plumb the pKVM MMU in KVM Sebastian Ott
2025-05-05 11:34 ` Marc Zyngier [this message]
2025-05-05 14:01 ` Sebastian Ott
2025-05-05 14:59 ` Marc Zyngier
2025-05-05 16:05 ` Sebastian Ott
2025-05-05 16:26 ` Marc Zyngier
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=86msbrguka.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.com \
--cc=sebott@redhat.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
/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.