The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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


  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