* linux-next: manual merge of the arm64 tree with the origin tree
@ 2026-01-26 15:11 Mark Brown
2026-01-26 15:23 ` Will Deacon
2026-01-26 15:39 ` Marc Zyngier
0 siblings, 2 replies; 9+ messages in thread
From: Mark Brown @ 2026-01-26 15:11 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Marc Zyngier,
Oliver Upton, Paolo Bonzini
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: linux-next: manual merge of the arm64 tree with the origin tree 2026-01-26 15:11 linux-next: manual merge of the arm64 tree with the origin tree Mark Brown @ 2026-01-26 15:23 ` Will Deacon 2026-01-26 15:53 ` Marc Zyngier 2026-01-26 16:08 ` Mark Brown 2026-01-26 15:39 ` Marc Zyngier 1 sibling, 2 replies; 9+ messages in thread From: Will Deacon @ 2026-01-26 15:23 UTC (permalink / raw) To: Mark Brown, maz Cc: Catalin Marinas, Linux Kernel Mailing List, Linux Next Mailing List, Oliver Upton, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the arm64 tree with the origin tree 2026-01-26 15:23 ` Will Deacon @ 2026-01-26 15:53 ` Marc Zyngier 2026-01-26 16:08 ` Mark Brown 1 sibling, 0 replies; 9+ messages in thread From: Marc Zyngier @ 2026-01-26 15:53 UTC (permalink / raw) To: Will Deacon Cc: Mark Brown, Catalin Marinas, Linux Kernel Mailing List, Linux Next Mailing List, Oliver Upton, Paolo Bonzini 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. ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the arm64 tree with the origin tree 2026-01-26 15:23 ` Will Deacon 2026-01-26 15:53 ` Marc Zyngier @ 2026-01-26 16:08 ` Mark Brown 1 sibling, 0 replies; 9+ messages in thread From: Mark Brown @ 2026-01-26 16:08 UTC (permalink / raw) To: Will Deacon Cc: maz, Catalin Marinas, Linux Kernel Mailing List, Linux Next Mailing List, Oliver Upton, Paolo Bonzini [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the arm64 tree with the origin tree 2026-01-26 15:11 linux-next: manual merge of the arm64 tree with the origin tree Mark Brown 2026-01-26 15:23 ` Will Deacon @ 2026-01-26 15:39 ` Marc Zyngier 2026-01-26 22:49 ` Mark Brown 1 sibling, 1 reply; 9+ messages in thread From: Marc Zyngier @ 2026-01-26 15:39 UTC (permalink / raw) To: Mark Brown Cc: Catalin Marinas, Will Deacon, Linux Kernel Mailing List, Linux Next Mailing List, Oliver Upton, Paolo Bonzini 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the arm64 tree with the origin tree 2026-01-26 15:39 ` Marc Zyngier @ 2026-01-26 22:49 ` Mark Brown 0 siblings, 0 replies; 9+ messages in thread From: Mark Brown @ 2026-01-26 22:49 UTC (permalink / raw) To: Marc Zyngier Cc: Catalin Marinas, Will Deacon, Linux Kernel Mailing List, Linux Next Mailing List, Oliver Upton, Paolo Bonzini [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* linux-next: manual merge of the arm64 tree with the origin tree
@ 2026-06-04 12:59 Mark Brown
0 siblings, 0 replies; 9+ messages in thread
From: Mark Brown @ 2026-06-04 12:59 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Marc Zyngier,
Mark Brown, Mark Rutland
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]
Hi all,
Today's linux-next merge of the arm64 tree got a conflict in:
arch/arm64/kvm/hyp/include/hyp/switch.h
between commit:
8372633074898 ("KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor")
from the origin tree and commits:
e1b163e405534 ("arm64: fpsimd: Use opaque type for SVE state")
2768101b39765 ("arm64: fpsimd: Move SVE save/restore inline")
1277531fca43d ("arm64: fpsimd: Split FPSR/FPCR from SVE save/restore")
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/kvm/hyp/include/hyp/switch.h
index 320cd45d49c5a,1f12c4ba295a4..0000000000000
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@@ -468,10 -466,9 +468,9 @@@ static inline void __hyp_sve_restore_gu
* The vCPU's saved SVE state layout always matches the max VL of the
* vCPU. Start off with the max VL so we can load the SVE state.
*/
- sve_cond_update_zcr_vq(vcpu_sve_max_vq(vcpu) - 1, SYS_ZCR_EL2);
+ sve_cond_update_zcr_vq(zcr_el2, SYS_ZCR_EL2);
- __sve_restore_state(vcpu_sve_pffr(vcpu),
- &vcpu->arch.ctxt.fp_regs.fpsr,
- true);
+ sve_load_state(kern_hyp_va(vcpu->arch.sve_state), true);
+ fpsimd_load_common(&vcpu->arch.ctxt.fp_regs);
/*
* The effective VL for a VM could differ from the max VL when running a
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* linux-next: manual merge of the arm64 tree with the origin tree
@ 2025-09-23 8:25 Mark Brown
2025-09-23 8:36 ` Will Deacon
0 siblings, 1 reply; 9+ messages in thread
From: Mark Brown @ 2025-09-23 8:25 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Dev Jain, Kees Cook, Linux Kernel Mailing List,
Linux Next Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: linux-next: manual merge of the arm64 tree with the origin tree 2025-09-23 8:25 Mark Brown @ 2025-09-23 8:36 ` Will Deacon 0 siblings, 0 replies; 9+ messages in thread From: Will Deacon @ 2025-09-23 8:36 UTC (permalink / raw) To: Mark Brown Cc: Catalin Marinas, Dev Jain, Kees Cook, Linux Kernel Mailing List, Linux Next Mailing List 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-06-04 12:59 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-26 15:11 linux-next: manual merge of the arm64 tree with the origin tree Mark Brown 2026-01-26 15:23 ` Will Deacon 2026-01-26 15:53 ` Marc Zyngier 2026-01-26 16:08 ` Mark Brown 2026-01-26 15:39 ` Marc Zyngier 2026-01-26 22:49 ` Mark Brown -- strict thread matches above, loose matches on Subject: below -- 2026-06-04 12:59 Mark Brown 2025-09-23 8:25 Mark Brown 2025-09-23 8:36 ` Will Deacon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox