linux-next: manual merge of the arm64 tree with the origin tree

linux-next: manual merge of the arm64 tree with the origin tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

Hi all,

Today's linux-next merge of the arm64 tree got a conflict in:

  arch/arm64/kvm/hyp/entry.S

between commit:

  86364832ba6f2 ("KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit")

from the origin tree and commit:

  018a231b0260e ("arm64: Unconditionally enable PAN support")

from the arm64 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.

[Took the version from Linus' tree.]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the arm64 tree with the origin tree

[Will Deacon]

On Mon, Jan 26, 2026 at 03:11:27PM +0000, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kvm/hyp/entry.S
> 
> between commit:
> 
>   86364832ba6f2 ("KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit")
> 
> from the origin tree and commit:
> 
>   018a231b0260e ("arm64: Unconditionally enable PAN support")
> 
> from the arm64 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.
> 
> [Took the version from Linus' tree.]

Hmm, I suspect that's not quite right because CONFIG_ARM64_PAN doesn't
exist anymore in the arm64 tree and so the hunk in
arch/arm64/kvm/va_layout.c probably needs tweaking.

Marc -- how would you prefer to handle this? I could bring back
CONFIG_ARM64_PAN as a hidden Kconfig option =y and then we could clean
up the stragglers at -rc1?

Will

Re: linux-next: manual merge of the arm64 tree with the origin tree

[Marc Zyngier]

On Mon, 26 Jan 2026 15:23:32 +0000,
Will Deacon <will@kernel.org> wrote:
> 
> On Mon, Jan 26, 2026 at 03:11:27PM +0000, Mark Brown wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the arm64 tree got a conflict in:
> > 
> >   arch/arm64/kvm/hyp/entry.S
> > 
> > between commit:
> > 
> >   86364832ba6f2 ("KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit")
> > 
> > from the origin tree and commit:
> > 
> >   018a231b0260e ("arm64: Unconditionally enable PAN support")
> > 
> > from the arm64 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.
> > 
> > [Took the version from Linus' tree.]
> 
> Hmm, I suspect that's not quite right because CONFIG_ARM64_PAN doesn't
> exist anymore in the arm64 tree and so the hunk in
> arch/arm64/kvm/va_layout.c probably needs tweaking.

The whole function in va_layout.c should simply disappear and whatever
is in arm64 be kept. That's what I did when I merged
arm64/for-next/cpufeature and kvm-arm64/vtcr in kvmarm/next.

But I now realise that because all these changes happen only in the
kvmarm/next branch (what was added is now removed), nobody sees that
outside of that tree, and next ends up with something that isn't quite
right.

> Marc -- how would you prefer to handle this? I could bring back
> CONFIG_ARM64_PAN as a hidden Kconfig option =y and then we could clean
> up the stragglers at -rc1?

As long as entry.S reflects what is in arm64 tree, we don't need this.
We just have a dangling patch function that is never called, and we
can cull that later. But if entry.S stays with Linus' version, then we
definitely need something of the sort.

FWIW, my own resolution is below.

Thanks,

	M.

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index ce516d8187b1b..a1ad12c72ebf1 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -300,8 +300,6 @@ void kvm_get_kimage_voffset(struct alt_instr *alt,
 	__le32 *origptr, __le32 *updptr, int nr_inst);
 void kvm_compute_final_ctr_el0(struct alt_instr *alt,
 	__le32 *origptr, __le32 *updptr, int nr_inst);
-void kvm_pan_patch_el2_entry(struct alt_instr *alt,
-			     __le32 *origptr, __le32 *updptr, int nr_inst);
 void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr, u64 elr_virt,
 	u64 elr_phys, u64 par, uintptr_t vcpu, u64 far, u64 hpfar);
 
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index d1ccddf9e87d9..11a10d8f5beb2 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -126,9 +126,7 @@ SYM_INNER_LABEL(__guest_exit, SYM_L_GLOBAL)
 
 	add	x1, x1, #VCPU_CONTEXT
 
-	alternative_cb ARM64_ALWAYS_SYSTEM, kvm_pan_patch_el2_entry
-	nop
-	alternative_cb_end
+	ALTERNATIVE(nop, SET_PSTATE_PAN(1), ARM64_HAS_PAN)
 
 	// Store the guest regs x2 and x3
 	stp	x2, x3,   [x1, #CPU_XREG_OFFSET(2)]
diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c
index bf888d150dc79..91b22a014610b 100644
--- a/arch/arm64/kvm/va_layout.c
+++ b/arch/arm64/kvm/va_layout.c
@@ -296,31 +296,3 @@ void kvm_compute_final_ctr_el0(struct alt_instr *alt,
 	generate_mov_q(read_sanitised_ftr_reg(SYS_CTR_EL0),
 		       origptr, updptr, nr_inst);
 }
-
-void kvm_pan_patch_el2_entry(struct alt_instr *alt,
-			     __le32 *origptr, __le32 *updptr, int nr_inst)
-{
-	/*
-	 * If we're running at EL1 without hVHE, then SCTLR_EL2.SPAN means
-	 * nothing to us (it is RES1), and we don't need to set PSTATE.PAN
-	 * to anything useful.
-	 */
-	if (!is_kernel_in_hyp_mode() && !cpus_have_cap(ARM64_KVM_HVHE))
-		return;
-
-	/*
-	 * Leap of faith: at this point, we must be running VHE one way or
-	 * another, and FEAT_PAN is required to be implemented. If KVM
-	 * explodes at runtime because your system does not abide by this
-	 * requirement, call your favourite HW vendor, they have screwed up.
-	 *
-	 * We don't expect hVHE to access any userspace mapping, so always
-	 * set PSTATE.PAN on enty. Same thing if we have PAN enabled on an
-	 * EL2 kernel. Only force it to 0 if we have not configured PAN in
-	 * the kernel (and you know this is really silly).
-	 */
-	if (cpus_have_cap(ARM64_KVM_HVHE) || IS_ENABLED(CONFIG_ARM64_PAN))
-		*updptr = cpu_to_le32(ENCODE_PSTATE(1, PAN));
-	else
-		*updptr = cpu_to_le32(ENCODE_PSTATE(0, PAN));
-}

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

Re: linux-next: manual merge of the arm64 tree with the origin tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Mon, Jan 26, 2026 at 03:23:32PM +0000, Will Deacon wrote:
> On Mon, Jan 26, 2026 at 03:11:27PM +0000, Mark Brown wrote:

> > [Took the version from Linus' tree.]

> Hmm, I suspect that's not quite right because CONFIG_ARM64_PAN doesn't
> exist anymore in the arm64 tree and so the hunk in
> arch/arm64/kvm/va_layout.c probably needs tweaking.

Indeed - there's updates needed elsewhere.

> Marc -- how would you prefer to handle this? I could bring back
> CONFIG_ARM64_PAN as a hidden Kconfig option =y and then we could clean
> up the stragglers at -rc1?

I guess you could also merge up -rc7 given that this is in Linus' tree?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the arm64 tree with the origin tree

[Marc Zyngier]

On Mon, 26 Jan 2026 15:11:27 +0000,
Mark Brown <broonie@kernel.org> wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> Hi all,
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kvm/hyp/entry.S
> 
> between commit:
> 
>   86364832ba6f2 ("KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit")
> 
> from the origin tree and commit:
> 
>   018a231b0260e ("arm64: Unconditionally enable PAN support")
> 
> from the arm64 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.
> 
> [Took the version from Linus' tree.]

I can't see the latest next yet, but this doesn't sound right.

The correct resolution for this is in the kvmarm/next branch,
effectively reverting most of 86364832ba6f2 ("KVM: arm64: Don't
blindly set set PSTATE.PAN on guest exit").

Keeping the version from Linus' tree doesn't work, as
kvm_pan_patch_el2_entry() references CONFIG_ARM64_PAN, which is
removed by 018a231b0260e ("arm64: Unconditionally enable PAN
support").

So the arm64 version should be the correct one.

Thanks,

	M.

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

Re: linux-next: manual merge of the arm64 tree with the origin tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

On Mon, Jan 26, 2026 at 03:39:39PM +0000, Marc Zyngier wrote:

> Keeping the version from Linus' tree doesn't work, as
> kvm_pan_patch_el2_entry() references CONFIG_ARM64_PAN, which is
> removed by 018a231b0260e ("arm64: Unconditionally enable PAN
> support").

I was expecting some fixup to be required in there, yes - at a first
glance the VHE based decisions looked like they'd still want to be made,
though I didn't check in detail.

> So the arm64 version should be the correct one.

I've applied a fixup doing that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the arm64 tree with the origin tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

Hi all,

Today's linux-next merge of the arm64 tree got a conflict in:

  arch/arm64/mm/mmu.c

between commit:

  ceca927c86e6f ("arm64: mm: Fix CFI failure due to kpti_ng_pgd_alloc function signature")

from the origin tree and commit:

  fa93b45fd397e ("arm64: Enable vmalloc-huge with ptdump")

from the arm64 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.

diff --cc arch/arm64/mm/mmu.c
index 980d7745a5499,10c2580995814..0000000000000
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@@ -47,6 -49,15 +49,8 @@@
  #define NO_CONT_MAPPINGS	BIT(1)
  #define NO_EXEC_MAPPINGS	BIT(2)	/* assumes FEAT_HPDS is not used */
  
 -enum pgtable_type {
 -	TABLE_PTE,
 -	TABLE_PMD,
 -	TABLE_PUD,
 -	TABLE_P4D,
 -};
 -
+ DEFINE_STATIC_KEY_FALSE(arm64_ptdump_lock_key);
+ 
  u64 kimage_voffset __ro_after_init;
  EXPORT_SYMBOL(kimage_voffset);
  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the arm64 tree with the origin tree

[Will Deacon]

On Tue, Sep 23, 2025 at 10:25:12AM +0200, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/mm/mmu.c
> 
> between commit:
> 
>   ceca927c86e6f ("arm64: mm: Fix CFI failure due to kpti_ng_pgd_alloc function signature")
> 
> from the origin tree and commit:
> 
>   fa93b45fd397e ("arm64: Enable vmalloc-huge with ptdump")
> 
> from the arm64 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.
> 
> diff --cc arch/arm64/mm/mmu.c
> index 980d7745a5499,10c2580995814..0000000000000
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@@ -47,6 -49,15 +49,8 @@@
>   #define NO_CONT_MAPPINGS	BIT(1)
>   #define NO_EXEC_MAPPINGS	BIT(2)	/* assumes FEAT_HPDS is not used */
>   
>  -enum pgtable_type {
>  -	TABLE_PTE,
>  -	TABLE_PMD,
>  -	TABLE_PUD,
>  -	TABLE_P4D,
>  -};
>  -
> + DEFINE_STATIC_KEY_FALSE(arm64_ptdump_lock_key);
> + 

Thanks, the the correct resolution. I'll merge in for-next/fixes soon
(we have a dangling patch that depends on it) so this will disappear.

Will