From: Steffen Eiden <seiden@linux.ibm.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Andreas Grapentin <gra@linux.ibm.com>,
Nina Schoetterl-Glausch <nsg@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
David Hildenbrand <david@kernel.org>,
kvm@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 1/2] kvm: rework memory prefault
Date: Tue, 26 May 2026 19:05:24 +0200 [thread overview]
Message-ID: <20260526170524.185462-A-seiden@linux.ibm.com> (raw)
In-Reply-To: <20260526125220.1560451-1-arnd@kernel.org>
On Tue, May 26, 2026 at 02:52:19PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When both s390 and arm64 KVM modules are enabled on s390,
> the latter fails to link against the s390 version of
> kvm_arch_vcpu_pre_fault_memory():
>
> ERROR: modpost: "kvm_arch_vcpu_pre_fault_memory" [arch/s390/kvm/arm64/kvm-arm64.ko] undefined!
>
> Change the logic to reference this based on a target
> specific macro rather than a global Kconfig symbol.
>
> Fixes: f67bba50ef56 ("KVM: s390: arm64: Enable KVM_ARM64 config and Kbuild")
> Fixes: 927ce4dee94f ("KVM: s390: Implement KVM_PRE_FAULT_MEMORY")
>
Thanks for looking into this.
An alternative solution could be for the kvm-arm64 module to just implement the
function as well. The s390 implementation is purely gmap based and has no
dependencies to s390-kvm beside that. arm on s390 kvm could use the exact same
implementation as well.
I guess this is probably dead code as (I assume) qemu-aarch64 does not use the feature.
But I saw some proposals regarding this feature for KVM/arm64 on the list.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This is not yet an actual problem, but will be when both
> the experimental 'sae' branch and the 7.2 contents from
> current linux-next are merged.
>
> Not sure who should carry this patch in the meantime, but
> it would be possible to add it to kvm-next already in
> preparation for the upcoming sae support.
I would prefer if you put it in next now. Less patches to carry around.
But If that is not feasible I can add it to series 1 once Claudios patches are
in 7.2.
Steffen
prev parent reply other threads:[~2026-05-26 17:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 12:52 [PATCH 1/2] kvm: rework memory prefault Arnd Bergmann
2026-05-26 12:52 ` [PATCH 2/2] s390: kvm: arm64: add HAS_IOMEM dependency Arnd Bergmann
2026-05-26 17:08 ` Steffen Eiden
2026-05-26 21:20 ` Arnd Bergmann
2026-05-26 17:05 ` Steffen Eiden [this message]
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=20260526170524.185462-A-seiden@linux.ibm.com \
--to=seiden@linux.ibm.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=borntraeger@linux.ibm.com \
--cc=david@kernel.org \
--cc=frankja@linux.ibm.com \
--cc=gra@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=nsg@linux.ibm.com \
/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.