From: Janosch Frank <frankja@linux.ibm.com>
To: Steffen Eiden <seiden@linux.ibm.com>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Cc: Alexander Gordeev <agordeev@linux.ibm.com>,
Andreas Grapentin <gra@linux.ibm.com>,
Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
David Hildenbrand <david@kernel.org>,
Friedrich Welter <fritz@linux.ibm.com>,
Gautam Gala <ggala@linux.ibm.com>,
Hariharan Mari <hari55@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Hendrik Brueckner <brueckner@linux.ibm.com>,
Ilya Leoshkevich <iii@linux.ibm.com>,
Joey Gouly <joey.gouly@arm.com>, Marc Zyngier <maz@kernel.org>,
Nico Boehr <nrb@linux.ibm.com>,
Nina Schoetterl-Glausch <oss@nina.schoetterlglausch.eu>,
Oliver Upton <oupton@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>, Will Deacon <will@kernel.org>,
Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v4 19/27] s390: Introduce Start Arm Execution instruction
Date: Mon, 6 Jul 2026 13:17:02 +0200 [thread overview]
Message-ID: <8239c9ba-154c-4e2d-b2fc-700ba12eb585@linux.ibm.com> (raw)
In-Reply-To: <20260706085229.979525-20-seiden@linux.ibm.com>
On 7/6/26 10:52, Steffen Eiden wrote:
> The Start Arm Execution (SAE) instruction is the centerpiece for
> executing arm64 (KVM) guests on s390. Its purpose is, similar to SIE, to
> enable accelerated execution of arm64 virtual machines. SAE expects the
> physical address of a control block as the only argument.
>
> The host is responsible to save & restore
> - GPRs 0-13
> - access register 0-15
> - breaking event register (BEAR)
> - vector/floating point registers
> between SAE executions to guarantee host consistency.
>
> GPRs and BEAR are save and restores in the asm functions. The other
> register are handled in within C code. Access registers are handled in a
> later patch and SVEs will be handled when they are introduced in a
> future series. Most arm64 registers are handled by a satellite block
> called save_area. Some registers, frequently used by hypervisors, are
> placed into the SAE control block itself.
>
> Enlighten asm/kvm_host_types.h for the new header variant. The new
> header is chosen instead of asm/kvm_host_s390_types.h if KVM_S390_ARM64
> is defined.
>
[...]
> + u64 gpr[31]; /* 0x0300 */
> + u64 _03f8; /* 0x03f8 */
> +
> + union {
> + u64 icptd[8]; /* 0x0400 */
> + /* validity-interception reason; icptr 0x01 */
> +#define SAE_VIR_UNKNOWN 0x00
> +#define SAE_VIR_UNSUPP_FORMAT 0x01
> +#define SAE_VIR_MSO_BOUNDS 0x02
> +#define SAE_VIR_MSLA 0x03
> +#define SAE_VIR_MGPAS 0x04
> +#define SAE_VIR_INVAL_SYSREG 0x05
> +#define SAE_VIR_HOST_CONTROL 0x06
> +#define SAE_VIR_SCA 0x07
> +#define SAE_VIR_MSO_ALIGN 0x08
> +#define SAE_VIR_HLC 0x09
> +#define SAE_VIR_IRPTC 0x0a
Will these ever be used for something?
> + u16 vir; /* 0x0400 */
> + /* host access interception details; icptr 0x02 */
> + struct {
> + u64 esr_elz; /* 0x0400 */
> + u8 _0408[6]; /* 0x0408 */
> + u16 pic; /* 0x040e */
> + union teid teid; /* 0x0410 */
> + gva_t far_elz; /* 0x0418 */
> + gva_t vaddr; /* 0x0420 */
> + u64 suppl; /* 0x0428 */
> + u8 gltl; /* 0x0430 */
> + u8 _0431[7]; /* 0x0431 */
> + u64 _0438; /* 0x0438 */
> + } hai;
> + /* exception-interception details; icptr 0x03 */
> + struct {
> + u64 esr_elz; /* 0x0400 */
> + u64 _0408[2]; /* 0x0408 */
> + gva_t far_elz; /* 0x0418 */
> + } trap;
> + /* timer-interception reason; icptr 0x04 */
> +#define SAE_IR_TIMER_ID_VIRT BIT(6)
> +#define SAE_IR_TIMER_ID_PHYS BIT(7)
> + u8 tir; /* 0x0400 */
> + };
> + u64 _0440[376]; /* 0x0440 */
> +} __packed __aligned(PAGE_SIZE);
> +static_assert(sizeof(struct kvm_sae_block) == PAGE_SIZE);
> +
[...]
> +#if IS_ENABLED(CONFIG_KVM_ARM64)
> +/*
> + * __sae64a calling convention:
> + * %r2 pointer to sae control block physical address
> + */
> +SYM_FUNC_START(__sae64a)
> + stmg %r6,%r14,__SF_GPRS(%r15) # store kernel registers
> + STBEAR __SF_SAE_BEAR(%r15) # save breaking event address register
> + .insn rre,0xb9a50000,%r2,0 # Start Arm Execution
> +# Let the next instruction be NOP to avoid triggering a machine check
> +# and handling it in a guest as result of the instruction execution.
@Christian:
I have the feeling things got lost in translation when this comment was
written.
How would we trigger a MCHECK by having an instruction after SIE/SAE?
AFAIU this allows us to have a label which we can check in the mcheck
handler to decide who triggered the mcheck.
Without the label the comment and NOP are useless as far as I can see.
So we need to decide if this still applies and then either remove it or
add sae handling to mcck_int_handler and maybe other mcheck functions.
> + nopr 7
> + LBEAR __SF_SAE_BEAR(%r15) # restore breaking event address register
> + lmg %r6,%r14,__SF_GPRS(%r15) # restore kernel registers
> + xgr %r0,%r0 # clear guest registers to
> + xgr %r1,%r1 # prevent speculative use
> + xgr %r3,%r3
> + xgr %r2,%r2
> + xgr %r4,%r4
> + xgr %r5,%r5
> + BR_EX %r14
> +SYM_FUNC_END(__sae64a)
> +EXPORT_SYMBOL(__sae64a)
> +#endif
> +
> /*
> * SVC interrupt handler routine. System calls are synchronous events and
> * are entered with interrupts disabled.
> diff --git a/arch/s390/tools/opcodes.txt b/arch/s390/tools/opcodes.txt
> index def2659f6602..0e4773c94af0 100644
> --- a/arch/s390/tools/opcodes.txt
> +++ b/arch/s390/tools/opcodes.txt
> @@ -594,6 +594,9 @@ b9a0 clp RRF_U0RR
> b9a1 tpei RRE_RR
> b9a2 ptf RRE_R0
> b9a4 uvc RRF_URR
> +b9a5 sae RRE_R0
> +b9a6 lasrm RRE_R0
> +b9a7 stiasrm RRE_R0
> b9aa lptea RRF_RURR2
> b9ab essa RRF_U0RR
> b9ac irbm RRE_RR
next prev parent reply other threads:[~2026-07-06 11:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 8:52 [PATCH v4 00/27] KVM: s390: Introduce arm64 KVM Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 01/27] VFIO: take reference to the KVM module Steffen Eiden
2026-07-06 19:53 ` Jason Gunthorpe
2026-07-06 21:12 ` Sean Christopherson
2026-07-06 8:52 ` [PATCH v4 02/27] KVM, vfio: remove symbol_get(kvm_get_kvm_safe) from vfio Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 03/27] KVM, vfio: remove symbol_get(kvm_put_kvm) " Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 04/27] KVM: Make device name configurable Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 05/27] KVM: Remove KVM_MMIO as config option Steffen Eiden
2026-07-06 20:53 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 06/27] arm64: Use proper include variant Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 07/27] arm64: Prepare sharing arm64 headers with s390 Steffen Eiden
2026-07-06 21:22 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 08/27] KVM: arm64: Prepare sharing arm64 code " Steffen Eiden
2026-07-06 21:28 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 09/27] KVM: arm64: Access elements of vcpu_gp_regs individually Steffen Eiden
2026-07-06 17:44 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 10/27] KVM: arm64: Refactor core-reset into a separate function Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 11/27] s390: Use arm64 headers Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 12/27] KVM: s390: Use arm64 code Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 13/27] KVM: s390: Prepare KVM/s390 for a second KVM module Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 14/27] KVM: s390: Move s390 kvm code into a subdirectory Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 15/27] KVM: S390: Prepare gmap for a second KVM implementation Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 16/27] KVM: s390: gmap: Refactor storage key and CMMA code into separate files Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 17/27] KVM: s390: Refactor prefix handling into a separate file Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 18/27] KVM: s390: Prepare kvm-s390 for a second kvm module Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 19/27] s390: Introduce Start Arm Execution instruction Steffen Eiden
2026-07-06 11:17 ` Janosch Frank [this message]
2026-07-06 11:30 ` Christian Borntraeger
2026-07-06 11:58 ` Steffen Eiden
2026-07-06 11:53 ` Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 20/27] KVM: s390: arm64: Introduce host definitions Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 21/27] s390/hwcaps: Report SAE support as hwcap Steffen Eiden
2026-07-06 11:50 ` Janosch Frank
2026-07-06 8:52 ` [PATCH v4 22/27] KVM: s390: Add basic arm64 kvm module Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 23/27] KVM: s390: arm64: Implement required functions Steffen Eiden
2026-07-06 12:15 ` Janosch Frank
2026-07-06 20:35 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 24/27] KVM: s390: arm64: Implement vm/vcpu create destroy Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 25/27] KVM: s390: arm64: Implement vCPU IOCTLs Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 26/27] KVM: s390: arm64: Implement basic page fault handler Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 27/27] KVM: s390: arm64: Enable KVM_ARM64 config and Kbuild Steffen Eiden
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=8239c9ba-154c-4e2d-b2fc-700ba12eb585@linux.ibm.com \
--to=frankja@linux.ibm.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=arnd@arndb.de \
--cc=borntraeger@linux.ibm.com \
--cc=brueckner@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=fritz@linux.ibm.com \
--cc=ggala@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=gra@linux.ibm.com \
--cc=hari55@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=maz@kernel.org \
--cc=nrb@linux.ibm.com \
--cc=oss@nina.schoetterlglausch.eu \
--cc=oupton@kernel.org \
--cc=pbonzini@redhat.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=svens@linux.ibm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox