linux-next: manual merge of the kvm-arm tree with the arm64 tree

Stephen Rothwell posted 1 patch 1 year, 1 month ago
There is a newer version of this series
linux-next: manual merge of the kvm-arm tree with the arm64 tree
Posted by Stephen Rothwell 1 year, 1 month ago
Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  arch/arm64/include/asm/kvm_emulate.h
  arch/arm64/kvm/fpsimd.c
  arch/arm64/kvm/hyp/nvhe/pkvm.c
  arch/arm64/kvm/hyp/nvhe/switch.c

between commit:

  e5ecedcd7cc2 ("arm64/sysreg: Get rid of CPACR_ELx SysregFields")

from the arm64 tree and commits:

  41d6028e28bd ("KVM: arm64: Convert the SVE guest vcpu flag to a vm flag")
  d381e53384a6 ("KVM: arm64: Move host SME/SVE tracking flags to host data")
  f50758260bff ("KVM: arm64: Group setting traps for protected VMs by control register")
  2fd5b4b0e7b4 ("KVM: arm64: Calculate cptr_el2 traps on activating traps")
(and maybe others)

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/kvm_emulate.h
index 4f1d99725f6b,2d91fb88298a..000000000000
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@@ -628,12 -629,12 +629,12 @@@ static __always_inline void __kvm_reset
  		if (cpus_have_final_cap(ARM64_SME))
  			val |= CPACR_EL1_SMEN_EL1EN;
  	} else if (has_hvhe()) {
 -		val = CPACR_ELx_FPEN;
 +		val = CPACR_EL1_FPEN;
  
- 		if (!vcpu_has_sve(vcpu) || !guest_owns_fp_regs())
+ 		if (!kvm_has_sve(kvm) || !guest_owns_fp_regs())
 -			val |= CPACR_ELx_ZEN;
 +			val |= CPACR_EL1_ZEN;
  		if (cpus_have_final_cap(ARM64_SME))
 -			val |= CPACR_ELx_SMEN;
 +			val |= CPACR_EL1_SMEN;
  	} else {
  		val = CPTR_NVHE_EL2_RES1;
  
diff --cc arch/arm64/kvm/fpsimd.c
index 98718bd65bf1,0e0f37d1990a..000000000000
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@@ -168,8 -168,8 +168,8 @@@ void kvm_arch_vcpu_put_fp(struct kvm_vc
  	 */
  	if (has_vhe() && system_supports_sme()) {
  		/* Also restore EL0 state seen on entry */
- 		if (vcpu_get_flag(vcpu, HOST_SME_ENABLED))
+ 		if (host_data_test_flag(HOST_SME_ENABLED))
 -			sysreg_clear_set(CPACR_EL1, 0, CPACR_ELx_SMEN);
 +			sysreg_clear_set(CPACR_EL1, 0, CPACR_EL1_SMEN);
  		else
  			sysreg_clear_set(CPACR_EL1,
  					 CPACR_EL1_SMEN_EL0EN,
diff --cc arch/arm64/kvm/hyp/nvhe/pkvm.c
index 73e319891327,918d8142da8f..000000000000
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
diff --cc arch/arm64/kvm/hyp/nvhe/switch.c
index 0f6b01b3da5c,0ebf84a9f9e2..000000000000
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@@ -36,33 -35,46 +35,46 @@@ DEFINE_PER_CPU(unsigned long, kvm_hyp_v
  
  extern void kvm_nvhe_prepare_backtrace(unsigned long fp, unsigned long pc);
  
- static void __activate_traps(struct kvm_vcpu *vcpu)
+ static void __activate_cptr_traps(struct kvm_vcpu *vcpu)
  {
- 	u64 val;
+ 	u64 val = CPTR_EL2_TAM;	/* Same bit irrespective of E2H */
  
- 	___activate_traps(vcpu, vcpu->arch.hcr_el2);
- 	__activate_traps_common(vcpu);
+ 	if (has_hvhe()) {
 -		val |= CPACR_ELx_TTA;
++		val |= CPACR_EL1_TTA;
  
- 	val = vcpu->arch.cptr_el2;
- 	val |= CPTR_EL2_TAM;	/* Same bit irrespective of E2H */
- 	val |= has_hvhe() ? CPACR_EL1_TTA : CPTR_EL2_TTA;
- 	if (cpus_have_final_cap(ARM64_SME)) {
- 		if (has_hvhe())
- 			val &= ~CPACR_EL1_SMEN;
- 		else
- 			val |= CPTR_EL2_TSM;
+ 		if (guest_owns_fp_regs()) {
 -			val |= CPACR_ELx_FPEN;
++			val |= CPACR_EL1_FPEN;
+ 			if (vcpu_has_sve(vcpu))
 -				val |= CPACR_ELx_ZEN;
++				val |= CPACR_EL1_ZEN;
+ 		}
+ 	} else {
+ 		val |= CPTR_EL2_TTA | CPTR_NVHE_EL2_RES1;
+ 
+ 		/*
+ 		 * Always trap SME since it's not supported in KVM.
+ 		 * TSM is RES1 if SME isn't implemented.
+ 		 */
+ 		val |= CPTR_EL2_TSM;
+ 
+ 		if (!vcpu_has_sve(vcpu) || !guest_owns_fp_regs())
+ 			val |= CPTR_EL2_TZ;
+ 
+ 		if (!guest_owns_fp_regs())
+ 			val |= CPTR_EL2_TFP;
  	}
  
- 	if (!guest_owns_fp_regs()) {
- 		if (has_hvhe())
- 			val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
- 		else
- 			val |= CPTR_EL2_TFP | CPTR_EL2_TZ;
- 
+ 	if (!guest_owns_fp_regs())
  		__activate_traps_fpsimd32(vcpu);
- 	}
  
  	kvm_write_cptr_el2(val);
+ }
+ 
+ static void __activate_traps(struct kvm_vcpu *vcpu)
+ {
+ 	___activate_traps(vcpu, vcpu->arch.hcr_el2);
+ 	__activate_traps_common(vcpu);
+ 	__activate_cptr_traps(vcpu);
+ 
  	write_sysreg(__this_cpu_read(kvm_hyp_vector), vbar_el2);
  
  	if (cpus_have_final_cap(ARM64_WORKAROUND_SPECULATIVE_AT)) {
Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
Posted by Marc Zyngier 1 year, 1 month ago
On Mon, 06 Jan 2025 03:53:03 +0000,
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> [1  <text/plain; US-ASCII (quoted-printable)>]
> Hi all,
> 
> Today's linux-next merge of the kvm-arm tree got conflicts in:
> 
>   arch/arm64/include/asm/kvm_emulate.h
>   arch/arm64/kvm/fpsimd.c
>   arch/arm64/kvm/hyp/nvhe/pkvm.c
>   arch/arm64/kvm/hyp/nvhe/switch.c
> 
> between commit:
> 
>   e5ecedcd7cc2 ("arm64/sysreg: Get rid of CPACR_ELx SysregFields")
> 
> from the arm64 tree and commits:
> 
>   41d6028e28bd ("KVM: arm64: Convert the SVE guest vcpu flag to a vm flag")
>   d381e53384a6 ("KVM: arm64: Move host SME/SVE tracking flags to host data")
>   f50758260bff ("KVM: arm64: Group setting traps for protected VMs by control register")
>   2fd5b4b0e7b4 ("KVM: arm64: Calculate cptr_el2 traps on activating traps")
> (and maybe others)
> 
> from the kvm-arm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.


Hi Stephen,

This looks OK to me, but we should fix this in the kvmarm tree.

Will: I'm going to merge the arm64/for-next/cpufeature branch back
into kvmarm/next -- shout if you foresee an issue with that.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.