Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 06/10] KVM: arm64: Offer early resume for non-blocking WFxT instructions
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

For WFxT instructions used with very small delays, it is not
unlikely that the deadline is already expired by the time we
reach the WFx handling code.

Check for this condition as soon as possible, and return to the
guest immediately if we can.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/handle_exit.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 4260f2cd1971..7726b01dc09a 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -80,12 +80,14 @@ static int handle_no_fpsimd(struct kvm_vcpu *vcpu)
  *
  * @vcpu:	the vcpu pointer
  *
- * WFE: Yield the CPU and come back to this vcpu when the scheduler
+ * WFE[T]: Yield the CPU and come back to this vcpu when the scheduler
  * decides to.
  * WFI: Simply call kvm_vcpu_halt(), which will halt execution of
  * world-switches and schedule other host processes until there is an
  * incoming IRQ or FIQ to the VM.
  * WFIT: Same as WFI, with a timed wakeup implemented as a background timer
+ *
+ * WF{I,E}T can immediately return if the deadline has already expired.
  */
 static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
 {
@@ -94,15 +96,35 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
 	if (esr & ESR_ELx_WFx_ISS_WFE) {
 		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
 		vcpu->stat.wfe_exit_stat++;
-		kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
 	} else {
 		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false);
 		vcpu->stat.wfi_exit_stat++;
-		if ((esr & (ESR_ELx_WFx_ISS_RV | ESR_ELx_WFx_ISS_WFxT)) == (ESR_ELx_WFx_ISS_RV | ESR_ELx_WFx_ISS_WFxT))
+	}
+
+	if (esr & ESR_ELx_WFx_ISS_WFxT) {
+		if (esr & ESR_ELx_WFx_ISS_RV) {
+			u64 val, now;
+
+			now = kvm_arm_timer_get_reg(vcpu, KVM_REG_ARM_TIMER_CNT);
+			val = vcpu_get_reg(vcpu, kvm_vcpu_sys_get_rt(vcpu));
+
+			if (now >= val)
+				goto out;
+		} else {
+			/* Treat WFxT as WFx if RN is invalid */
+			esr &= ~ESR_ELx_WFx_ISS_WFxT;
+		}
+	}
+
+	if (esr & ESR_ELx_WFx_ISS_WFE) {
+		kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
+	} else {
+		if (esr & ESR_ELx_WFx_ISS_WFxT)
 			vcpu->arch.flags |= KVM_ARM64_WFIT;
+
 		kvm_vcpu_wfi(vcpu);
 	}
-
+out:
 	kvm_incr_pc(vcpu);
 
 	return 1;
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 03/10] KVM: arm64: Simplify kvm_cpu_has_pending_timer()
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

kvm_cpu_has_pending_timer() ends up checking all the possible
timers for a wake-up cause. However, we already check for
pending interrupts whenever we try to wake-up a vcpu, including
the timer interrupts.

Obviously, doing the same work twice is once too many. Reduce
this helper to almost nothing, but keep it around, as we are
going to make use of it soon.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/arch_timer.c  | 10 ++--------
 arch/arm64/kvm/arm.c         |  5 -----
 include/kvm/arm_arch_timer.h |  2 --
 3 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 6e542e2eae32..16dda1a383a6 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -350,15 +350,9 @@ static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx)
 	return cval <= now;
 }
 
-bool kvm_timer_is_pending(struct kvm_vcpu *vcpu)
+int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
 {
-	struct timer_map map;
-
-	get_timer_map(vcpu, &map);
-
-	return kvm_timer_should_fire(map.direct_vtimer) ||
-	       kvm_timer_should_fire(map.direct_ptimer) ||
-	       kvm_timer_should_fire(map.emul_ptimer);
+	return 0;
 }
 
 /*
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 523bc934fe2f..2122c699af06 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -356,11 +356,6 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
 	kvm_arm_vcpu_destroy(vcpu);
 }
 
-int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
-{
-	return kvm_timer_is_pending(vcpu);
-}
-
 void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu)
 {
 
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index 51c19381108c..cd6d8f260eab 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -76,8 +76,6 @@ int kvm_arm_timer_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
 int kvm_arm_timer_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
 int kvm_arm_timer_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
 
-bool kvm_timer_is_pending(struct kvm_vcpu *vcpu);
-
 u64 kvm_phys_timer_read(void);
 
 void kvm_timer_vcpu_load(struct kvm_vcpu *vcpu);
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 04/10] KVM: arm64: Introduce kvm_counter_compute_delta() helper
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

Refactor kvm_timer_compute_delta() and extract a helper that
compute the delta (in ns) between a given timer and an arbitrary
value.

No functional change expected.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/arch_timer.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 16dda1a383a6..c92a68190f6a 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -208,18 +208,16 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static u64 kvm_timer_compute_delta(struct arch_timer_context *timer_ctx)
+static u64 kvm_counter_compute_delta(struct arch_timer_context *timer_ctx,
+				     u64 val)
 {
-	u64 cval, now;
-
-	cval = timer_get_cval(timer_ctx);
-	now = kvm_phys_timer_read() - timer_get_offset(timer_ctx);
+	u64 now = kvm_phys_timer_read() - timer_get_offset(timer_ctx);
 
-	if (now < cval) {
+	if (now < val) {
 		u64 ns;
 
 		ns = cyclecounter_cyc2ns(timecounter->cc,
-					 cval - now,
+					 val - now,
 					 timecounter->mask,
 					 &timecounter->frac);
 		return ns;
@@ -228,6 +226,11 @@ static u64 kvm_timer_compute_delta(struct arch_timer_context *timer_ctx)
 	return 0;
 }
 
+static u64 kvm_timer_compute_delta(struct arch_timer_context *timer_ctx)
+{
+	return kvm_counter_compute_delta(timer_ctx, timer_get_cval(timer_ctx));
+}
+
 static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx)
 {
 	WARN_ON(timer_ctx && timer_ctx->loaded);
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 05/10] KVM: arm64: Handle blocking WFIT instruction
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

When trapping a blocking WFIT instruction, take it into account when
computing the deadline of the background timer.

The state is tracked with a new vcpu flag, and is gated by a new
CPU capability, which isn't currently enabled.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/arch_timer.c       | 22 ++++++++++++++++++++--
 arch/arm64/kvm/arm.c              |  1 +
 arch/arm64/kvm/handle_exit.c      |  7 ++++++-
 arch/arm64/tools/cpucaps          |  1 +
 5 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index e3b25dc6c367..9e6e8701933e 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -441,6 +441,7 @@ struct kvm_vcpu_arch {
 #define KVM_ARM64_DEBUG_STATE_SAVE_TRBE	(1 << 13) /* Save TRBE context if active  */
 #define KVM_ARM64_FP_FOREIGN_FPSTATE	(1 << 14)
 #define KVM_ARM64_ON_UNSUPPORTED_CPU	(1 << 15) /* Physical CPU not in supported_cpus */
+#define KVM_ARM64_WFIT			(1 << 16) /* WFIT instruction trapped */
 
 #define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE | \
 				 KVM_GUESTDBG_USE_SW_BP | \
diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index c92a68190f6a..4e39ace073af 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -239,6 +239,20 @@ static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx)
 		  (ARCH_TIMER_CTRL_IT_MASK | ARCH_TIMER_CTRL_ENABLE)) == ARCH_TIMER_CTRL_ENABLE);
 }
 
+static bool vcpu_has_wfit_active(struct kvm_vcpu *vcpu)
+{
+	return (cpus_have_final_cap(ARM64_HAS_WFXT) &&
+		(vcpu->arch.flags & KVM_ARM64_WFIT));
+}
+
+static u64 wfit_delay_ns(struct kvm_vcpu *vcpu)
+{
+	struct arch_timer_context *ctx = vcpu_vtimer(vcpu);
+	u64 val = vcpu_get_reg(vcpu, kvm_vcpu_sys_get_rt(vcpu));
+
+	return kvm_counter_compute_delta(ctx, val);
+}
+
 /*
  * Returns the earliest expiration time in ns among guest timers.
  * Note that it will return 0 if none of timers can fire.
@@ -256,6 +270,9 @@ static u64 kvm_timer_earliest_exp(struct kvm_vcpu *vcpu)
 			min_delta = min(min_delta, kvm_timer_compute_delta(ctx));
 	}
 
+	if (vcpu_has_wfit_active(vcpu))
+		min_delta = min(min_delta, wfit_delay_ns(vcpu));
+
 	/* If none of timers can fire, then return 0 */
 	if (min_delta == ULLONG_MAX)
 		return 0;
@@ -355,7 +372,7 @@ static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx)
 
 int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
 {
-	return 0;
+	return vcpu_has_wfit_active(vcpu) && wfit_delay_ns(vcpu) == 0;
 }
 
 /*
@@ -481,7 +498,8 @@ static void kvm_timer_blocking(struct kvm_vcpu *vcpu)
 	 */
 	if (!kvm_timer_irq_can_fire(map.direct_vtimer) &&
 	    !kvm_timer_irq_can_fire(map.direct_ptimer) &&
-	    !kvm_timer_irq_can_fire(map.emul_ptimer))
+	    !kvm_timer_irq_can_fire(map.emul_ptimer) &&
+	    !vcpu_has_wfit_active(vcpu))
 		return;
 
 	/*
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 2122c699af06..e7cb8a4d2e81 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -634,6 +634,7 @@ void kvm_vcpu_wfi(struct kvm_vcpu *vcpu)
 	preempt_enable();
 
 	kvm_vcpu_halt(vcpu);
+	vcpu->arch.flags &= ~KVM_ARM64_WFIT;
 	kvm_clear_request(KVM_REQ_UNHALT, vcpu);
 
 	preempt_disable();
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 97fe14aab1a3..4260f2cd1971 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -85,16 +85,21 @@ static int handle_no_fpsimd(struct kvm_vcpu *vcpu)
  * WFI: Simply call kvm_vcpu_halt(), which will halt execution of
  * world-switches and schedule other host processes until there is an
  * incoming IRQ or FIQ to the VM.
+ * WFIT: Same as WFI, with a timed wakeup implemented as a background timer
  */
 static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
 {
-	if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
+	u64 esr = kvm_vcpu_get_esr(vcpu);
+
+	if (esr & ESR_ELx_WFx_ISS_WFE) {
 		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
 		vcpu->stat.wfe_exit_stat++;
 		kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
 	} else {
 		trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false);
 		vcpu->stat.wfi_exit_stat++;
+		if ((esr & (ESR_ELx_WFx_ISS_RV | ESR_ELx_WFx_ISS_WFxT)) == (ESR_ELx_WFx_ISS_RV | ESR_ELx_WFx_ISS_WFxT))
+			vcpu->arch.flags |= KVM_ARM64_WFIT;
 		kvm_vcpu_wfi(vcpu);
 	}
 
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 3ed418f70e3b..01f7d253dec4 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -38,6 +38,7 @@ HAS_STAGE2_FWB
 HAS_SYSREG_GIC_CPUIF
 HAS_TLB_RANGE
 HAS_VIRT_HOST_EXTN
+HAS_WFXT
 HW_DBM
 KVM_PROTECTED_MODE
 MISMATCHED_CACHE_TYPE
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 08/10] arm64: Add HWCAP advertising FEAT_WFXT
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

In order to allow userspace to enjoy WFET, add a new HWCAP that
advertises it when available.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 Documentation/arm64/cpu-feature-registers.rst | 2 ++
 Documentation/arm64/elf_hwcaps.rst            | 4 ++++
 arch/arm64/include/asm/hwcap.h                | 1 +
 arch/arm64/include/uapi/asm/hwcap.h           | 1 +
 arch/arm64/kernel/cpufeature.c                | 3 ++-
 arch/arm64/kernel/cpuinfo.c                   | 1 +
 6 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst
index 749ae970c319..04ba83e1965f 100644
--- a/Documentation/arm64/cpu-feature-registers.rst
+++ b/Documentation/arm64/cpu-feature-registers.rst
@@ -290,6 +290,8 @@ infrastructure:
      +------------------------------+---------+---------+
      | RPRES                        | [7-4]   |    y    |
      +------------------------------+---------+---------+
+     | WFXT                         | [3-0]   |    y    |
+     +------------------------------+---------+---------+
 
 
 Appendix I: Example
diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst
index a8f30963e550..af3ab524e826 100644
--- a/Documentation/arm64/elf_hwcaps.rst
+++ b/Documentation/arm64/elf_hwcaps.rst
@@ -264,6 +264,10 @@ HWCAP2_MTE3
     Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
     by Documentation/arm64/memory-tagging-extension.rst.
 
+HWCAP2_WFXT
+
+    Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
+
 4. Unused AT_HWCAP bits
 -----------------------
 
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index 8db5ec0089db..909337b50e1f 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -109,6 +109,7 @@
 #define KERNEL_HWCAP_AFP		__khwcap2_feature(AFP)
 #define KERNEL_HWCAP_RPRES		__khwcap2_feature(RPRES)
 #define KERNEL_HWCAP_MTE3		__khwcap2_feature(MTE3)
+#define KERNEL_HWCAP_WFXT		__khwcap2_feature(WFXT)
 
 /*
  * This yields a mask that user programs can use to figure out what
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 99cb5d383048..9dddde1d046c 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -79,5 +79,6 @@
 #define HWCAP2_AFP		(1 << 20)
 #define HWCAP2_RPRES		(1 << 21)
 #define HWCAP2_MTE3		(1 << 22)
+#define HWCAP2_WFXT		(1 << 23)
 
 #endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index db6d9ab685e5..945190ebadd5 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -237,7 +237,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
 		       FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_GPA3_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_RPRES_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_WFXT_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_WFXT_SHIFT, 4, 0),
 	ARM64_FTR_END,
 };
 
@@ -2587,6 +2587,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 	HWCAP_CAP(SYS_ID_AA64MMFR0_EL1, ID_AA64MMFR0_ECV_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_ECV),
 	HWCAP_CAP(SYS_ID_AA64MMFR1_EL1, ID_AA64MMFR1_AFP_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_AFP),
 	HWCAP_CAP(SYS_ID_AA64ISAR2_EL1, ID_AA64ISAR2_RPRES_SHIFT, 4, FTR_UNSIGNED, 1, CAP_HWCAP, KERNEL_HWCAP_RPRES),
+	HWCAP_CAP(SYS_ID_AA64ISAR2_EL1, ID_AA64ISAR2_WFXT_SHIFT, 4, FTR_UNSIGNED, ID_AA64ISAR2_WFXT_SUPPORTED, CAP_HWCAP, KERNEL_HWCAP_WFXT),
 	{},
 };
 
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 330b92ea863a..781eab314794 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -98,6 +98,7 @@ static const char *const hwcap_str[] = {
 	[KERNEL_HWCAP_AFP]		= "afp",
 	[KERNEL_HWCAP_RPRES]		= "rpres",
 	[KERNEL_HWCAP_MTE3]		= "mte3",
+	[KERNEL_HWCAP_WFXT]		= "wfxt",
 };
 
 #ifdef CONFIG_COMPAT
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 02/10] arm64: Add RV and RN fields for ESR_ELx_WFx_ISS
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

The ISS field exposed by ESR_ELx contain two additional subfields
with FEAT_WFxT:

- RN, the register number containing the timeout
- RV, indicating if the register number is valid

Describe these two fields according to the arch spec.

No functional change.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/include/asm/esr.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 65c2201b11b2..15156c478054 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -133,6 +133,8 @@
 #define ESR_ELx_CV		(UL(1) << 24)
 #define ESR_ELx_COND_SHIFT	(20)
 #define ESR_ELx_COND_MASK	(UL(0xF) << ESR_ELx_COND_SHIFT)
+#define ESR_ELx_WFx_ISS_RN	(UL(0x1F) << 5)
+#define ESR_ELx_WFx_ISS_RV	(UL(1) << 2)
 #define ESR_ELx_WFx_ISS_TI	(UL(3) << 0)
 #define ESR_ELx_WFx_ISS_WFxT	(UL(2) << 0)
 #define ESR_ELx_WFx_ISS_WFI	(UL(0) << 0)
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 09/10] arm64: Add wfet()/wfit() helpers
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

Just like we have helpers for WFI and WFE, add the WFxT versions.
Note that the encoding is that reported by objdump, as no currrent
toolchain knows about these instructions yet.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/include/asm/barrier.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 62217be36217..9f3e2c3d2ca0 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -16,7 +16,11 @@
 
 #define sev()		asm volatile("sev" : : : "memory")
 #define wfe()		asm volatile("wfe" : : : "memory")
+#define wfet(val)	asm volatile("msr s0_3_c1_c0_0, %0"	\
+				     : : "r" (val) : "memory")
 #define wfi()		asm volatile("wfi" : : : "memory")
+#define wfit(val)	asm volatile("msr s0_3_c1_c0_1, %0"	\
+				     : : "r" (val) : "memory")
 
 #define isb()		asm volatile("isb" : : : "memory")
 #define dmb(opt)	asm volatile("dmb " #opt : : : "memory")
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 00/10] arm64: Add initial support for FEAT_WFxT
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team

The ARMv8.7 WFxT feature is a new take on the good old WFI/WFE
instructions as they behave the same way, only taking an extra timeout
parameter.

This small series aims at adding the minimal support for this feature,
enabling it for both the kernel and KVM.

A potential addition to this series would be to remove the event
generation from the counters, and rely on the timeout where it
matters (spinlocks?). Feedback welcome.

Patches on top of 5.18-rc2, tested of the FVP AEM.

* From v1 [1]:
  - Properly generate traces even if the deadline has already expired
  - Collect RBs, with thanks.

[1] https://lore.kernel.org/r/20220412131303.504690-1-maz@kernel.org

Marc Zyngier (10):
  arm64: Expand ESR_ELx_WFx_ISS_TI to match its ARMv8.7 definition
  arm64: Add RV and RN fields for ESR_ELx_WFx_ISS
  KVM: arm64: Simplify kvm_cpu_has_pending_timer()
  KVM: arm64: Introduce kvm_counter_compute_delta() helper
  KVM: arm64: Handle blocking WFIT instruction
  KVM: arm64: Offer early resume for non-blocking WFxT instructions
  KVM: arm64: Expose the WFXT feature to guests
  arm64: Add HWCAP advertising FEAT_WFXT
  arm64: Add wfet()/wfit() helpers
  arm64: Use WFxT for __delay() when possible

 Documentation/arm64/cpu-feature-registers.rst |  2 +
 Documentation/arm64/elf_hwcaps.rst            |  4 ++
 arch/arm64/include/asm/barrier.h              |  4 ++
 arch/arm64/include/asm/esr.h                  |  8 +++-
 arch/arm64/include/asm/hwcap.h                |  1 +
 arch/arm64/include/asm/kvm_host.h             |  1 +
 arch/arm64/include/uapi/asm/hwcap.h           |  1 +
 arch/arm64/kernel/cpufeature.c                | 13 +++++
 arch/arm64/kernel/cpuinfo.c                   |  1 +
 arch/arm64/kvm/arch_timer.c                   | 47 ++++++++++++-------
 arch/arm64/kvm/arm.c                          |  6 +--
 arch/arm64/kvm/handle_exit.c                  | 35 ++++++++++++--
 arch/arm64/kvm/sys_regs.c                     |  2 +
 arch/arm64/lib/delay.c                        | 12 ++++-
 arch/arm64/tools/cpucaps                      |  1 +
 include/kvm/arm_arch_timer.h                  |  2 -
 16 files changed, 110 insertions(+), 30 deletions(-)

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 07/10] KVM: arm64: Expose the WFXT feature to guests
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

Plumb in the capability, and expose WFxT to guests when available.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 12 ++++++++++++
 arch/arm64/kvm/sys_regs.c      |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d72c4b4d389c..db6d9ab685e5 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -237,6 +237,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
 		       FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_GPA3_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_RPRES_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_WFXT_SHIFT, 4, 0),
 	ARM64_FTR_END,
 };
 
@@ -2442,6 +2443,17 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.matches = has_cpuid_feature,
 		.min_field_value = 1,
 	},
+	{
+		.desc = "WFx with timeout",
+		.capability = ARM64_HAS_WFXT,
+		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.sys_reg = SYS_ID_AA64ISAR2_EL1,
+		.sign = FTR_UNSIGNED,
+		.field_pos = ID_AA64ISAR2_WFXT_SHIFT,
+		.field_width = 4,
+		.matches = has_cpuid_feature,
+		.min_field_value = ID_AA64ISAR2_WFXT_SUPPORTED,
+	},
 	{},
 };
 
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 7b45c040cc27..cc9a77546cc0 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1144,6 +1144,8 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
 		if (!vcpu_has_ptrauth(vcpu))
 			val &= ~(ARM64_FEATURE_MASK(ID_AA64ISAR2_APA3) |
 				 ARM64_FEATURE_MASK(ID_AA64ISAR2_GPA3));
+		if (!cpus_have_final_cap(ARM64_HAS_WFXT))
+			val &= ~ARM64_FEATURE_MASK(ID_AA64ISAR2_WFXT);
 		break;
 	case SYS_ID_AA64DFR0_EL1:
 		/* Limit debug to ARMv8.0 */
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH 2/6] ARM: dts: bcm2837-rpi-cm3-io3: Fix GPIO line names for SMPS I2C
From: Florian Fainelli @ 2022-04-19 18:28 UTC (permalink / raw)
  To: bcm-kernel-feedback-list, Stefan Wahren, Ray Jui, Scott Branden,
	Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Linus Walleij, devicetree,
	linux-rpi-kernel, linux-arm-kernel, Phil Elwell
In-Reply-To: <20220411200143.4876-3-stefan.wahren@i2se.com>

On Mon, 11 Apr 2022 22:01:39 +0200, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> From: Phil Elwell <phil@raspberrypi.com>
> 
> The GPIOs 46 & 47 are already used for a I2C interface to a SMPS.
> So fix the GPIO line names accordingly.
> 
> Fixes: a54fe8a6cf66 ("ARM: dts: add Raspberry Pi Compute Module 3 and IO board")
> Signed-off-by: Phil Elwell <phil@raspberrypi.com>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 3/6] ARM: dts: bcm2837-rpi-3-b-plus: Fix GPIO line name of power LED
From: Florian Fainelli @ 2022-04-19 18:28 UTC (permalink / raw)
  To: bcm-kernel-feedback-list, Stefan Wahren, Ray Jui, Scott Branden,
	Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Linus Walleij, devicetree,
	linux-rpi-kernel, linux-arm-kernel, Phil Elwell
In-Reply-To: <20220411200143.4876-4-stefan.wahren@i2se.com>

On Mon, 11 Apr 2022 22:01:40 +0200, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> From: Phil Elwell <phil@raspberrypi.com>
> 
> The red LED on the Raspberry Pi 3 B Plus is the power LED.
> So fix the GPIO line name accordingly.
> 
> Fixes: 71c0cd2283f2 ("ARM: dts: bcm2837: Add Raspberry Pi 3 B+")
> Signed-off-by: Phil Elwell <phil@raspberrypi.com>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 4/6] ARM: dts: bcm2835-rpi-b: Fix GPIO line names
From: Florian Fainelli @ 2022-04-19 18:28 UTC (permalink / raw)
  To: bcm-kernel-feedback-list, Stefan Wahren, Ray Jui, Scott Branden,
	Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Linus Walleij, devicetree,
	linux-rpi-kernel, linux-arm-kernel, Phil Elwell
In-Reply-To: <20220411200143.4876-5-stefan.wahren@i2se.com>

On Mon, 11 Apr 2022 22:01:41 +0200, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Recently this has been fixed in the vendor tree, so upstream this.
> 
> Fixes: 731b26a6ac17 ("ARM: bcm2835: Add names for the Raspberry Pi GPIO lines")
> Signed-off-by: Phil Elwell <phil@raspberrypi.com>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 5/6] ARM: dts: bcm283x: Remove gpio line name NC
From: Florian Fainelli @ 2022-04-19 18:28 UTC (permalink / raw)
  To: bcm-kernel-feedback-list, Stefan Wahren, Ray Jui, Scott Branden,
	Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Linus Walleij, devicetree,
	linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <20220411200143.4876-6-stefan.wahren@i2se.com>

On Mon, 11 Apr 2022 22:01:42 +0200, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> The convention to name not connected GPIOs with NC has never been
> adapted. Also newer Raspberry Pi boards like RPi 4 never did. So fix
> this inconsistency by removing all of the NC names.
> 
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 6/6] ARM: dts: bcm283x: Align ETH_CLK GPIO line name
From: Florian Fainelli @ 2022-04-19 18:29 UTC (permalink / raw)
  To: bcm-kernel-feedback-list, Stefan Wahren, Ray Jui, Scott Branden,
	Rob Herring, Krzysztof Kozlowski
  Cc: Nicolas Saenz Julienne, Linus Walleij, devicetree,
	linux-rpi-kernel, linux-arm-kernel, Phil Elwell
In-Reply-To: <20220411200143.4876-7-stefan.wahren@i2se.com>

On Mon, 11 Apr 2022 22:01:43 +0200, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> From: Phil Elwell <phil@raspberrypi.com>
> 
> The GPIO line name ETHCLK is not aligned with the other signals like
> WIFI_CLK. Recently this has been fixed in the vendor tree, so upstream
> this change.
> 
> Signed-off-by: Phil Elwell <phil@raspberrypi.com>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 7/9] mm: Calc the right pfn if page size is not 4K
From: Ard Biesheuvel @ 2022-04-19 18:29 UTC (permalink / raw)
  To: Anshuman Khandual, Andrew Morton
  Cc: Wupeng Ma, Catalin Marinas, Will Deacon, Jonathan Corbet,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	X86 ML, hpa, Darren Hart, Andy Shevchenko, Mike Rapoport,
	Paul E. McKenney, Peter Zijlstra, Joerg Roedel, songmuchun, macro,
	Frederic Weisbecker, W_Armin, John Garry, Sean Christopherson,
	Thomas Bogendoerfer, chenhuacai, David Hildenbrand, gpiccoli,
	Mark Rutland, Kefeng Wang, Linux Doc Mailing List,
	Linux Kernel Mailing List, Linux ARM, linux-efi, linux-ia64,
	platform-driver-x86, Linux Memory Management List
In-Reply-To: <672ff459-81bd-38ef-882d-e718992d295c@arm.com>

On Tue, 19 Apr 2022 at 13:13, Anshuman Khandual
<anshuman.khandual@arm.com> wrote:
>
>
>
> On 4/14/22 15:43, Wupeng Ma wrote:
> > From: Ma Wupeng <mawupeng1@huawei.com>
> >
> > Previous 0x100000 is used to check the 4G limit in
> > find_zone_movable_pfns_for_nodes(). This is right in x86 because
> > the page size can only be 4K. But 16K and 64K are available in
> > arm64. So replace it with PHYS_PFN(SZ_4G).
> >
> > Signed-off-by: Ma Wupeng <mawupeng1@huawei.com>
> > ---
> >  mm/page_alloc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 6e5b4488a0c5..570d0ebf98df 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -7870,7 +7870,7 @@ static void __init find_zone_movable_pfns_for_nodes(void)
> >
> >                       usable_startpfn = memblock_region_memory_base_pfn(r);
> >
> > -                     if (usable_startpfn < 0x100000) {
> > +                     if (usable_startpfn < PHYS_PFN(SZ_4G)) {
> >                               mem_below_4gb_not_mirrored = true;
> >                               continue;
> >                       }
>
> Regardless PFN value should never be encoded directly.
>
> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>

Acked-by: Ard Biesheuvel <ardb@kernel.org>

Andrew, can you please take this one through the -mm tree? The rest of
the series needs a bit more work, but is an obvious fix and there is
no point in holding it up.

Thanks,
Ard.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] ARM: dts: BCM5301X: Disable gmac0 and enable port@8 on Asus RT-AC88U
From: Florian Fainelli @ 2022-04-19 18:30 UTC (permalink / raw)
  To: Arınç ÜNAL, Florian Fainelli,
	Rafał Miłecki, Hauke Mehrtens, Rob Herring
  Cc: linux-kernel, linux-arm-kernel, devicetree,
	bcm-kernel-feedback-list
In-Reply-To: <20220410094454.2788-1-arinc.unal@arinc9.com>



On 4/10/2022 2:44 AM, Arınç ÜNAL wrote:
> Disable gmac0 which is not connected to any switch MAC. Enable port@8 of
> the Broadcom switch which is connected to gmac2.
> 
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, 
thanks!
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 0/9] introduce mirrored memory support for arm64
From: Ard Biesheuvel @ 2022-04-19 18:32 UTC (permalink / raw)
  To: mawupeng
  Cc: Andrew Morton, Catalin Marinas, Will Deacon, Jonathan Corbet,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
	X86 ML, hpa, Darren Hart, Andy Shevchenko, Mike Rapoport,
	Paul E. McKenney, Peter Zijlstra, Joerg Roedel, songmuchun, macro,
	Frederic Weisbecker, W_Armin, John Garry, Sean Christopherson,
	Thomas Bogendoerfer, Anshuman Khandual, chenhuacai,
	David Hildenbrand, gpiccoli, Mark Rutland, Kefeng Wang,
	Linux Doc Mailing List, Linux Kernel Mailing List, Linux ARM,
	linux-efi, linux-ia64, platform-driver-x86,
	Linux Memory Management List
In-Reply-To: <6de859df-e1c3-e9aa-4530-3b61b9c69a28@huawei.com>

On Sat, 16 Apr 2022 at 03:32, mawupeng <mawupeng1@huawei.com> wrote:
>
>
>
> 在 2022/4/14 18:22, Ard Biesheuvel 写道:
> > On Thu, 14 Apr 2022 at 11:54, Wupeng Ma <mawupeng1@huawei.com> wrote:
> >>
> >> From: Ma Wupeng <mawupeng1@huawei.com>
> >>
> >> Commit b05b9f5f9dcf ("x86, mirror: x86 enabling - find mirrored memory ranges")
> >> introduced mirrored memory support for x86. This support rely on UEFI to
> >> report mirrored memory address ranges.  See UEFI 2.5 spec pages 157-158:
> >>
> >>    http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf
> >>
> >> Memory mirroring is a technique used to separate memory into two separate
> >> channels, usually on a memory device, like a server. In memory mirroring,
> >> one channel is copied to another to create redundancy. This method makes
> >> input/output (I/O) registers and memory appear with more than one address
> >> range because the same physical byte is accessible at more than one
> >> address. Using memory mirroring, higher memory reliability and a higher
> >> level of memory consolidation are possible.
> >>
> >> Arm64 can support this too. So mirrored memory support is added to support
> >> arm64.
> >>
> >> Efi_fake_mem is used for testing mirrored features and will not be used in
> >> production environment. This test features can fake memory's attribute
> >> values.
> >>
> >> The reason why efi_fake_mem support is put first is that memory's attribute
> >> is reported by BIOS which is hard to simulate. With this support, any arm64
> >> machines with efi support can easily test mirrored features.
> >>
> >> The main purpose of this patchset is to introduce mirrored support for
> >> arm64 and we have already fixed the problems we had which is shown in
> >> patch #5 to patch #7 and try to bring total isolation in patch #8 which
> >> will disable mirror feature if kernelcore is not specified.
> >>
> >> In order to test this support in arm64:
> >> - patch this patchset
> >> - add efi_fake_mem=8G@0:0x10000 in kernel parameter to simulate mirrored
> >>    memroy between phy addr 0-8G.
> >> - add kernelcore=mirror in kernel parameter
> >> - start you kernel
> >>
> >
> > As I explained before:
> >
> > - NAK to EFI fake_mem support on arm64
>
> fake_mem support on arm64 will be removed in subsequent version.
>
> > - NAK to the whole series until you come up with a proposal on how to
> > locate the static kernel image itself into more reliable memory, as
> > there is really no point to any of this otherwise.
>
> Sorry I am not familiar with this, as you metioned before,
>
>  > you have to iterate over the memory map and look for regions with
>  > the desired attribute, and allocate those pages explicitly.
>
> Do you mean this is x86, commit c05cd79750fb
> ("x86/boot/KASLR: Prefer mirrored memory regions for the kernel physical address").
> I will do some research.
>
>  > I'd prefer to implement this in the bootloader, and only add minimal
>  > logic to the stub to respect the placement of the kernel by the loader
>  > if the loader signals it to do so.
>
> Does this bootloader refer to grub and then add minimal logic to arm64-stub.c?
>

Any bootloader, yes.

> What is the loader signal?

A protocol installed onto the image handle, as I suggested before. I
even cc'ed you on a patch that implements this.

> System exists mirrored memory reported by uefi?
>

What on earth is the point of any of this if the only use case being
targeted is efi_fake_mem with arbitrary fake mirrored regions?

So yes, unless there are systems that need this, I don't see a point
in merging any of this.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH 00/17] KVM: arm64: Parallelize stage 2 fault handling
From: Oliver Upton @ 2022-04-19 18:36 UTC (permalink / raw)
  To: Ben Gardon
  Cc: kvmarm, kvm, Marc Zyngier, James Morse, Alexandru Elisei,
	Suzuki K Poulose, linux-arm-kernel, Peter Shier, Ricardo Koller,
	Reiji Watanabe, Paolo Bonzini, Sean Christopherson, David Matlack
In-Reply-To: <CANgfPd8V5AdH0dEAox2PvKJpqDrqmfJyiwoLpxEGqVfb7EEP9Q@mail.gmail.com>

On Tue, Apr 19, 2022 at 10:57 AM Ben Gardon <bgardon@google.com> wrote:
>
> On Fri, Apr 15, 2022 at 2:59 PM Oliver Upton <oupton@google.com> wrote:
> >
> > Presently KVM only takes a read lock for stage 2 faults if it believes
> > the fault can be fixed by relaxing permissions on a PTE (write unprotect
> > for dirty logging). Otherwise, stage 2 faults grab the write lock, which
> > predictably can pile up all the vCPUs in a sufficiently large VM.
> >
> > The x86 port of KVM has what it calls the TDP MMU. Basically, it is an
> > MMU protected by the combination of a read-write lock and RCU, allowing
> > page walkers to traverse in parallel.
> >
> > This series is strongly inspired by the mechanics of the TDP MMU,
> > making use of RCU to protect parallel walks. Note that the TLB
> > invalidation mechanics are a bit different between x86 and ARM, so we
> > need to use the 'break-before-make' sequence to split/collapse a
> > block/table mapping, respectively.
> >
> > Nonetheless, using atomics on the break side allows fault handlers to
> > acquire exclusive access to a PTE (lets just call it locked). Once the
> > PTE lock is acquired it is then safe to assume exclusive access.
> >
> > Special consideration is required when pruning the page tables in
> > parallel. Suppose we are collapsing a table into a block. Allowing
> > parallel faults means that a software walker could be in the middle of
> > a lower level traversal when the table is unlinked. Table
> > walkers that prune the paging structures must now 'lock' all descendent
> > PTEs, effectively asserting exclusive ownership of the substructure
> > (no other walker can install something to an already locked pte).
> >
> > Additionally, for parallel walks we need to punt the freeing of table
> > pages to the next RCU sync, as there could be multiple observers of the
> > table until all walkers exit the RCU critical section. For this I
> > decided to cram an rcu_head into page private data for every table page.
> > We wind up spending a bit more on table pages now, but lazily allocating
> > for rcu callbacks probably doesn't make a lot of sense. Not only would
> > we need a large cache of them (think about installing a level 1 block)
> > to wire up callbacks on all descendent tables, but we also then need to
> > spend memory to actually free memory.
>
> FWIW we used a similar approach in early versions of the TDP MMU, but
> instead of page->private used page->lru so that more metadata could be
> stored in page->private.
> Ultimately that ended up being too limiting and we decided to switch
> to just using the associated struct kvm_mmu_page as the list element.
> I don't know if ARM has an equivalent construct though.

ARM currently doesn't have any metadata it needs to tie with the table
pages. We just do very basic page reference counting for every valid
PTE. I was going to link together pages (hence the page header), but
we actually do not have a functional need for it at the moment. In
fact, struct page::rcu_head would probably fit the bill and we can
avoid extra metadata/memory for the time being.

Perhaps best to keep it simple and do the rest when we have a genuine
need for it.

--
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 07/11] x86: use fallback for random_get_entropy() instead of zero
From: Jason A. Donenfeld @ 2022-04-19 18:38 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: LKML, Linux Crypto Mailing List, Thomas Gleixner, Arnd Bergmann,
	Theodore Ts'o, Dominik Brodowski, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Thomas Bogendoerfer, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	David S . Miller, Richard Weinberger, Anton Ivanov, Johannes Berg,
	Ingo Molnar, Dave Hansen, H . Peter Anvin, Chris Zankel,
	Max Filippov, Stephen Boyd, Dinh Nguyen, linux-arm-kernel,
	linux-m68k, open list:BROADCOM NVRAM DRIVER, linux-riscv,
	sparclinux, linux-um, X86 ML, linux-xtensa
In-Reply-To: <Yl78gLLcSb3EHv0B@zn.tnic>

Hi Borislav,

On Tue, Apr 19, 2022 at 8:16 PM Borislav Petkov <bp@alien8.de> wrote:
> > +static inline unsigned long random_get_entropy(void)
> > +{
> > +#ifndef CONFIG_X86_TSC
> > +     if (!boot_cpu_has(X86_FEATURE_TSC))
>
> cpu_feature_enabled() pls.

This function began as a carbon copy of get_cycles(), which reads:

static inline cycles_t get_cycles(void)
{
#ifndef CONFIG_X86_TSC
       if (!boot_cpu_has(X86_FEATURE_TSC))
               return 0;
#endif

       return rdtsc();
}

As you see, random_get_entropy() is the same function, but with that
zero replaced with the fallback. (Using the fallback in get_cycles()
wouldn't be appropriate.)

So, your options are:
a) We keep this patch as-is, using boot_cpu_has(); or
b) I make an unrelated change inside of this same patch to change
get_cycles() to use cpu_feature_enabled() (in addition to the new
random_get_entropy()).

I think I prefer doing (a), and leaving (b) for another time when you
or another x86 maintainer can do so. But I'll do whichever you say.
Which would you like?

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 10/10] arm64: Use WFxT for __delay() when possible
From: Marc Zyngier @ 2022-04-19 18:27 UTC (permalink / raw)
  To: linux-arm-kernel, kvmarm, kvm
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
	Suzuki K Poulose, Alexandru Elisei, Joey Gouly, kernel-team
In-Reply-To: <20220419182755.601427-1-maz@kernel.org>

Marginally optimise __delay() by using a WFIT/WFET sequence.
It probably is a win if no interrupt fires during the delay.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/lib/delay.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
index 1688af0a4c97..5b7890139bc2 100644
--- a/arch/arm64/lib/delay.c
+++ b/arch/arm64/lib/delay.c
@@ -27,7 +27,17 @@ void __delay(unsigned long cycles)
 {
 	cycles_t start = get_cycles();
 
-	if (arch_timer_evtstrm_available()) {
+	if (cpus_have_const_cap(ARM64_HAS_WFXT)) {
+		u64 end = start + cycles;
+
+		/*
+		 * Start with WFIT. If an interrupt makes us resume
+		 * early, use a WFET loop to complete the delay.
+		 */
+		wfit(end);
+		while ((get_cycles() - start) < cycles)
+			wfet(end);
+	} else 	if (arch_timer_evtstrm_available()) {
 		const cycles_t timer_evt_period =
 			USECS_TO_CYCLES(ARCH_TIMER_EVT_STREAM_PERIOD_US);
 
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH] drivers/bus/brcmstb_gisb.c : Remove the suppress_bind_attrs attribute of the driver
From: Florian Fainelli @ 2022-04-19 18:49 UTC (permalink / raw)
  To: lizhe, f.fainelli, bcm-kernel-feedback-list, linux-arm-kernel
  Cc: linux-kernel
In-Reply-To: <20220320064529.12827-1-sensor1010@163.com>



On 3/19/2022 11:45 PM, lizhe wrote:
> Even if platform_driver does not set suppress_bind_attrs attribute,
> when registering with platform_driver_probe,  the value of
> suppress_bind_attrs is still true, see __platform_driver_probe()
> 
> Signed-off-by: lizhe <sensor1010@163.com>

Applied with a revised subject, thanks!
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] MAINTAINERS: add raspberrypi to BCM2835 architecture
From: Florian Fainelli @ 2022-04-19 18:58 UTC (permalink / raw)
  To: bcm-kernel-feedback-list, Stefan Wahren, Ray Jui, Scott Branden
  Cc: Nicolas Saenz Julienne, Ivan T . Ivanov, linux-kernel,
	linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <20220409184017.114804-1-stefan.wahren@i2se.com>

On Sat,  9 Apr 2022 20:40:17 +0200, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Recent changes to the firmware clock driver have not be send
> to the architecture maintainers. So fix this by adding the
> matching pattern.
> 
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/maintainers/next, thanks!
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 07/11] x86: use fallback for random_get_entropy() instead of zero
From: Borislav Petkov @ 2022-04-19 18:59 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: LKML, Linux Crypto Mailing List, Thomas Gleixner, Arnd Bergmann,
	Theodore Ts'o, Dominik Brodowski, Russell King,
	Catalin Marinas, Will Deacon, Geert Uytterhoeven,
	Thomas Bogendoerfer, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	David S . Miller, Richard Weinberger, Anton Ivanov, Johannes Berg,
	Ingo Molnar, Dave Hansen, H . Peter Anvin, Chris Zankel,
	Max Filippov, Stephen Boyd, Dinh Nguyen, linux-arm-kernel,
	linux-m68k, open list:BROADCOM NVRAM DRIVER, linux-riscv,
	sparclinux, linux-um, X86 ML, linux-xtensa
In-Reply-To: <CAHmME9q03Je-ROzzHCgZC0vy1n=y8bsGBOAs8U_K_r3ebLNHbw@mail.gmail.com>

On Tue, Apr 19, 2022 at 08:38:41PM +0200, Jason A. Donenfeld wrote:
> I think I prefer doing (a), and leaving (b) for another time when you
> or another x86 maintainer can do so. But I'll do whichever you say.
> Which would you like?

We are switching all feature checks to cpu_feature_enabled() so you
might as well do the new preferred way of checking when adding a
new function and so that we have one less place to touch. Which is
appreciated. :)

Thx!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 13/14] dt-bindings: pinctrl: add binding for Ralink RT305X pinctrl
From: Arınç ÜNAL @ 2022-04-19 18:59 UTC (permalink / raw)
  To: Rob Herring
  Cc: Sergio Paracuellos, Luiz Angelo Daros de Luca, Linus Walleij,
	Krzysztof Kozlowski, Thomas Bogendoerfer, Matthias Brugger,
	Joe Perches, erkin.bozoglu, linux-gpio, devicetree,
	linux-arm-kernel, linux-mediatek, linux-kernel, linux-mips
In-Reply-To: <Yl758u9iIMnhYPz2@robh.at.kernel.org>

On 19/04/2022 21:05, Rob Herring wrote:
> On Thu, Apr 14, 2022 at 08:39:15PM +0300, Arınç ÜNAL wrote:
>> Add binding for the Ralink RT305X pin controller for RT3050, RT3052,
>> RT3350, RT3352 and RT5350 SoCs.
>>
>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>> ---
>>   .../pinctrl/ralink,rt305x-pinctrl.yaml        | 92 +++++++++++++++++++
>>   1 file changed, 92 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
>> new file mode 100644
>> index 000000000000..425401c54269
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml
>> @@ -0,0 +1,92 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pinctrl/ralink,rt305x-pinctrl.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Ralink RT305X Pin Controller
>> +
>> +maintainers:
>> +  - Arınç ÜNAL <arinc.unal@arinc9.com>
>> +  - Sergio Paracuellos <sergio.paracuellos@gmail.com>
>> +
>> +description:
>> +  Ralink RT305X pin controller for RT3050, RT3052, RT3350, RT3352 and RT5350
>> +  SoCs.
>> +  The pin controller can only set the muxing of pin groups. Muxing individual
>> +  pins is not supported. There is no pinconf support.
>> +
>> +properties:
>> +  compatible:
>> +    const: ralink,rt305x-pinctrl
> 
> You should have a compatible for each SoC unless these are all just
> fused or package varients of the same chip.

The rt305x pin controller calls code from 
arch/mips/include/asm/mach-ralink/rt305x.h to determine the SoC and uses 
different pinmux data by the result of the determination.

I guess we can call this fused.

Arınç

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext
From: Russell King (Oracle) @ 2022-04-19 18:57 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage,
	Stephen Rothwell, Arnd Bergmann, Ard Biesheuvel, Andrew Morton,
	max.krummenacher, Shawn Guo, Stefano Stabellini,
	Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman
In-Reply-To: <CA+G9fYuACgY2hcAgh_LwVb9AURjodMJbV6SsJb90wj-0aJKUOw@mail.gmail.com>

On Tue, Apr 19, 2022 at 04:28:52PM +0530, Naresh Kamboju wrote:
> Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard
> x15 device.

Was the immediately previous linux-next behaving correctly?

If so, nothing has changed in the ARM32 kernel tree, so this must be
someone else's issue - code that someone else has pushed into
linux-next.

It looks to me like someone is walking the page tables incorrectly,
somewhere buried in handle_mm_fault(), because the PTE pointer is in
the upper-2k of a 4k page, which is most definitely illegal on arm32.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox