* [PATCH 17/24] KVM: arm64: Remove obsolete kvm_virt_to_phys abstraction
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Andrew Scull <ascull@google.com>
This abstraction was introduced to hide the difference between arm and
arm64 but, with the former no longer supported, this abstraction can be
removed and the canonical kernel API used directly instead.
Signed-off-by: Andrew Scull <ascull@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
CC: Marc Zyngier <maz@kernel.org>
CC: James Morse <james.morse@arm.com>
CC: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20200519104036.259917-1-ascull@google.com
---
arch/arm64/include/asm/kvm_mmu.h | 2 --
arch/arm64/kvm/mmu.c | 6 +++---
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 796f6a2e794a..53bd4d517a4d 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -363,8 +363,6 @@ static inline void __kvm_flush_dcache_pud(pud_t pud)
}
}
-#define kvm_virt_to_phys(x) __pa_symbol(x)
-
void kvm_set_way_flush(struct kvm_vcpu *vcpu);
void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index ddf85bf21897..a1f6bc70c4e4 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2197,11 +2197,11 @@ int kvm_mmu_init(void)
{
int err;
- hyp_idmap_start = kvm_virt_to_phys(__hyp_idmap_text_start);
+ hyp_idmap_start = __pa_symbol(__hyp_idmap_text_start);
hyp_idmap_start = ALIGN_DOWN(hyp_idmap_start, PAGE_SIZE);
- hyp_idmap_end = kvm_virt_to_phys(__hyp_idmap_text_end);
+ hyp_idmap_end = __pa_symbol(__hyp_idmap_text_end);
hyp_idmap_end = ALIGN(hyp_idmap_end, PAGE_SIZE);
- hyp_idmap_vector = kvm_virt_to_phys(__kvm_hyp_init);
+ hyp_idmap_vector = __pa_symbol(__kvm_hyp_init);
/*
* We rely on the linker script to ensure at build time that the HYP
--
2.26.2
_______________________________________________
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 15/24] KVM: arm64: Clean up cpu_init_hyp_mode()
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: David Brazdil <dbrazdil@google.com>
Pull bits of code to the only place where it is used. Remove empty function
__cpu_init_stage2(). Remove redundant has_vhe() check since this function is
nVHE-only. No functional changes intended.
Signed-off-by: David Brazdil <dbrazdil@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200515152056.83158-1-dbrazdil@google.com
---
arch/arm64/include/asm/kvm_asm.h | 2 ++
arch/arm64/include/asm/kvm_host.h | 35 -------------------------------
arch/arm64/kvm/arm.c | 32 +++++++++++++++++++++++-----
3 files changed, 29 insertions(+), 40 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 59e314f38e43..0c9b5fc4ba0a 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -70,6 +70,8 @@ extern int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu);
extern int __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu);
+extern void __kvm_enable_ssbs(void);
+
extern u64 __vgic_v3_get_ich_vtr_el2(void);
extern u64 __vgic_v3_read_vmcr(void);
extern void __vgic_v3_write_vmcr(u32 vmcr);
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a723f84fab83..69a338a390a6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -533,39 +533,6 @@ static inline void kvm_init_host_cpu_context(struct kvm_cpu_context *cpu_ctxt)
cpu_ctxt->sys_regs[MPIDR_EL1] = read_cpuid_mpidr();
}
-void __kvm_enable_ssbs(void);
-
-static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
- unsigned long hyp_stack_ptr,
- unsigned long vector_ptr)
-{
- /*
- * Calculate the raw per-cpu offset without a translation from the
- * kernel's mapping to the linear mapping, and store it in tpidr_el2
- * so that we can use adr_l to access per-cpu variables in EL2.
- */
- u64 tpidr_el2 = ((u64)this_cpu_ptr(&kvm_host_data) -
- (u64)kvm_ksym_ref(kvm_host_data));
-
- /*
- * Call initialization code, and switch to the full blown HYP code.
- * If the cpucaps haven't been finalized yet, something has gone very
- * wrong, and hyp will crash and burn when it uses any
- * cpus_have_const_cap() wrapper.
- */
- BUG_ON(!system_capabilities_finalized());
- __kvm_call_hyp((void *)pgd_ptr, hyp_stack_ptr, vector_ptr, tpidr_el2);
-
- /*
- * Disabling SSBD on a non-VHE system requires us to enable SSBS
- * at EL2.
- */
- if (!has_vhe() && this_cpu_has_cap(ARM64_SSBS) &&
- arm64_get_ssbd_state() == ARM64_SSBD_FORCE_DISABLE) {
- kvm_call_hyp(__kvm_enable_ssbs);
- }
-}
-
static inline bool kvm_arch_requires_vhe(void)
{
/*
@@ -601,8 +568,6 @@ int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
struct kvm_device_attr *attr);
-static inline void __cpu_init_stage2(void) {}
-
/* Guest/host FPSIMD coordination helpers */
int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu);
void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index e01d44df98df..b0b569f2cdd0 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1273,19 +1273,41 @@ static void cpu_init_hyp_mode(void)
{
phys_addr_t pgd_ptr;
unsigned long hyp_stack_ptr;
- unsigned long stack_page;
unsigned long vector_ptr;
+ unsigned long tpidr_el2;
/* Switch from the HYP stub to our own HYP init vector */
__hyp_set_vectors(kvm_get_idmap_vector());
+ /*
+ * Calculate the raw per-cpu offset without a translation from the
+ * kernel's mapping to the linear mapping, and store it in tpidr_el2
+ * so that we can use adr_l to access per-cpu variables in EL2.
+ */
+ tpidr_el2 = ((unsigned long)this_cpu_ptr(&kvm_host_data) -
+ (unsigned long)kvm_ksym_ref(kvm_host_data));
+
pgd_ptr = kvm_mmu_get_httbr();
- stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
- hyp_stack_ptr = stack_page + PAGE_SIZE;
+ hyp_stack_ptr = __this_cpu_read(kvm_arm_hyp_stack_page) + PAGE_SIZE;
vector_ptr = (unsigned long)kvm_get_hyp_vector();
- __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
- __cpu_init_stage2();
+ /*
+ * Call initialization code, and switch to the full blown HYP code.
+ * If the cpucaps haven't been finalized yet, something has gone very
+ * wrong, and hyp will crash and burn when it uses any
+ * cpus_have_const_cap() wrapper.
+ */
+ BUG_ON(!system_capabilities_finalized());
+ __kvm_call_hyp((void *)pgd_ptr, hyp_stack_ptr, vector_ptr, tpidr_el2);
+
+ /*
+ * Disabling SSBD on a non-VHE system requires us to enable SSBS
+ * at EL2.
+ */
+ if (this_cpu_has_cap(ARM64_SSBS) &&
+ arm64_get_ssbd_state() == ARM64_SSBD_FORCE_DISABLE) {
+ kvm_call_hyp(__kvm_enable_ssbs);
+ }
}
static void cpu_hyp_reset(void)
--
2.26.2
_______________________________________________
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 21/24] KVM: arm64: Move sysreg reset check to boot time
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
Our sysreg reset check has become a bit silly, as it only checks whether
a reset callback actually exists for a given sysreg entry, and apply the
method if available. Doing the check at each vcpu reset is pretty dumb,
as the tables never change. It is thus perfectly possible to do the same
checks at boot time.
This also allows us to introduce a sparse sys_regs[] array, something
that will be required with ARMv8.4-NV.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/sys_regs.c | 72 +++++++++++++++++++--------------------
1 file changed, 35 insertions(+), 37 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 9d28eabbdf97..ad1d57501d6d 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2087,12 +2087,37 @@ static const struct sys_reg_desc cp15_64_regs[] = {
{ SYS_DESC(SYS_AARCH32_CNTP_CVAL), access_arch_timer },
};
+static int check_sysreg_table(const struct sys_reg_desc *table, unsigned int n,
+ bool is_32)
+{
+ unsigned int i;
+
+ for (i = 0; i < n; i++) {
+ if (!is_32 && table[i].reg && !table[i].reset) {
+ kvm_err("sys_reg table %p entry %d has lacks reset\n",
+ table, i);
+ return 1;
+ }
+
+ if (i && cmp_sys_reg(&table[i-1], &table[i]) >= 0) {
+ kvm_err("sys_reg table %p out of order (%d)\n", table, i - 1);
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
/* Target specific emulation tables */
static struct kvm_sys_reg_target_table *target_tables[KVM_ARM_NUM_TARGETS];
void kvm_register_target_sys_reg_table(unsigned int target,
struct kvm_sys_reg_target_table *table)
{
+ if (check_sysreg_table(table->table64.table, table->table64.num, false) ||
+ check_sysreg_table(table->table32.table, table->table32.num, true))
+ return;
+
target_tables[target] = table;
}
@@ -2378,19 +2403,13 @@ static int emulate_sys_reg(struct kvm_vcpu *vcpu,
}
static void reset_sys_reg_descs(struct kvm_vcpu *vcpu,
- const struct sys_reg_desc *table, size_t num,
- unsigned long *bmap)
+ const struct sys_reg_desc *table, size_t num)
{
unsigned long i;
for (i = 0; i < num; i++)
- if (table[i].reset) {
- int reg = table[i].reg;
-
+ if (table[i].reset)
table[i].reset(vcpu, &table[i]);
- if (reg > 0 && reg < NR_SYS_REGS)
- set_bit(reg, bmap);
- }
}
/**
@@ -2846,32 +2865,18 @@ int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *uindices)
return write_demux_regids(uindices);
}
-static int check_sysreg_table(const struct sys_reg_desc *table, unsigned int n)
-{
- unsigned int i;
-
- for (i = 1; i < n; i++) {
- if (cmp_sys_reg(&table[i-1], &table[i]) >= 0) {
- kvm_err("sys_reg table %p out of order (%d)\n", table, i - 1);
- return 1;
- }
- }
-
- return 0;
-}
-
void kvm_sys_reg_table_init(void)
{
unsigned int i;
struct sys_reg_desc clidr;
/* Make sure tables are unique and in order. */
- BUG_ON(check_sysreg_table(sys_reg_descs, ARRAY_SIZE(sys_reg_descs)));
- BUG_ON(check_sysreg_table(cp14_regs, ARRAY_SIZE(cp14_regs)));
- BUG_ON(check_sysreg_table(cp14_64_regs, ARRAY_SIZE(cp14_64_regs)));
- BUG_ON(check_sysreg_table(cp15_regs, ARRAY_SIZE(cp15_regs)));
- BUG_ON(check_sysreg_table(cp15_64_regs, ARRAY_SIZE(cp15_64_regs)));
- BUG_ON(check_sysreg_table(invariant_sys_regs, ARRAY_SIZE(invariant_sys_regs)));
+ BUG_ON(check_sysreg_table(sys_reg_descs, ARRAY_SIZE(sys_reg_descs), false));
+ BUG_ON(check_sysreg_table(cp14_regs, ARRAY_SIZE(cp14_regs), true));
+ BUG_ON(check_sysreg_table(cp14_64_regs, ARRAY_SIZE(cp14_64_regs), true));
+ BUG_ON(check_sysreg_table(cp15_regs, ARRAY_SIZE(cp15_regs), true));
+ BUG_ON(check_sysreg_table(cp15_64_regs, ARRAY_SIZE(cp15_64_regs), true));
+ BUG_ON(check_sysreg_table(invariant_sys_regs, ARRAY_SIZE(invariant_sys_regs), false));
/* We abuse the reset function to overwrite the table itself. */
for (i = 0; i < ARRAY_SIZE(invariant_sys_regs); i++)
@@ -2907,17 +2912,10 @@ void kvm_reset_sys_regs(struct kvm_vcpu *vcpu)
{
size_t num;
const struct sys_reg_desc *table;
- DECLARE_BITMAP(bmap, NR_SYS_REGS) = { 0, };
/* Generic chip reset first (so target could override). */
- reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs), bmap);
+ reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs));
table = get_target_table(vcpu->arch.target, true, &num);
- reset_sys_reg_descs(vcpu, table, num, bmap);
-
- for (num = 1; num < NR_SYS_REGS; num++) {
- if (WARN(!test_bit(num, bmap),
- "Didn't reset __vcpu_sys_reg(%zi)\n", num))
- break;
- }
+ reset_sys_reg_descs(vcpu, table, num);
}
--
2.26.2
_______________________________________________
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 18/24] KVM: arm64: vgic-v3: Take cpu_if pointer directly instead of vcpu
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Christoffer Dall <christoffer.dall@arm.com>
If we move the used_lrs field to the version-specific cpu interface
structure, the following functions only operate on the struct
vgic_v3_cpu_if and not the full vcpu:
__vgic_v3_save_state
__vgic_v3_restore_state
__vgic_v3_activate_traps
__vgic_v3_deactivate_traps
__vgic_v3_save_aprs
__vgic_v3_restore_aprs
This is going to be very useful for nested virt, so move the used_lrs
field and change the prototypes and implementations of these functions to
take the cpu_if parameter directly.
No functional change.
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/include/asm/kvm_hyp.h | 12 ++++++------
arch/arm64/kvm/hyp/switch.c | 8 ++++----
arch/arm64/kvm/hyp/vgic-v3-sr.c | 33 ++++++++++----------------------
arch/arm64/kvm/vgic/vgic-v2.c | 10 +++++-----
arch/arm64/kvm/vgic/vgic-v3.c | 14 ++++++++------
arch/arm64/kvm/vgic/vgic.c | 25 ++++++++++++++++--------
include/kvm/arm_vgic.h | 5 ++++-
7 files changed, 54 insertions(+), 53 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index fe57f60f06a8..4f67b0cdffe8 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -56,12 +56,12 @@
int __vgic_v2_perform_cpuif_access(struct kvm_vcpu *vcpu);
-void __vgic_v3_save_state(struct kvm_vcpu *vcpu);
-void __vgic_v3_restore_state(struct kvm_vcpu *vcpu);
-void __vgic_v3_activate_traps(struct kvm_vcpu *vcpu);
-void __vgic_v3_deactivate_traps(struct kvm_vcpu *vcpu);
-void __vgic_v3_save_aprs(struct kvm_vcpu *vcpu);
-void __vgic_v3_restore_aprs(struct kvm_vcpu *vcpu);
+void __vgic_v3_save_state(struct vgic_v3_cpu_if *cpu_if);
+void __vgic_v3_restore_state(struct vgic_v3_cpu_if *cpu_if);
+void __vgic_v3_activate_traps(struct vgic_v3_cpu_if *cpu_if);
+void __vgic_v3_deactivate_traps(struct vgic_v3_cpu_if *cpu_if);
+void __vgic_v3_save_aprs(struct vgic_v3_cpu_if *cpu_if);
+void __vgic_v3_restore_aprs(struct vgic_v3_cpu_if *cpu_if);
int __vgic_v3_perform_cpuif_access(struct kvm_vcpu *vcpu);
void __timer_enable_traps(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 8a1e81a400e0..c07a45643cd4 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -270,8 +270,8 @@ static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
static void __hyp_text __hyp_vgic_save_state(struct kvm_vcpu *vcpu)
{
if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif)) {
- __vgic_v3_save_state(vcpu);
- __vgic_v3_deactivate_traps(vcpu);
+ __vgic_v3_save_state(&vcpu->arch.vgic_cpu.vgic_v3);
+ __vgic_v3_deactivate_traps(&vcpu->arch.vgic_cpu.vgic_v3);
}
}
@@ -279,8 +279,8 @@ static void __hyp_text __hyp_vgic_save_state(struct kvm_vcpu *vcpu)
static void __hyp_text __hyp_vgic_restore_state(struct kvm_vcpu *vcpu)
{
if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif)) {
- __vgic_v3_activate_traps(vcpu);
- __vgic_v3_restore_state(vcpu);
+ __vgic_v3_activate_traps(&vcpu->arch.vgic_cpu.vgic_v3);
+ __vgic_v3_restore_state(&vcpu->arch.vgic_cpu.vgic_v3);
}
}
diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 6b85773e15c4..10ed539835c1 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -194,10 +194,9 @@ static u32 __hyp_text __vgic_v3_read_ap1rn(int n)
return val;
}
-void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
+void __hyp_text __vgic_v3_save_state(struct vgic_v3_cpu_if *cpu_if)
{
- struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
- u64 used_lrs = vcpu->arch.vgic_cpu.used_lrs;
+ u64 used_lrs = cpu_if->used_lrs;
/*
* Make sure stores to the GIC via the memory mapped interface
@@ -230,10 +229,9 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
}
}
-void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
+void __hyp_text __vgic_v3_restore_state(struct vgic_v3_cpu_if *cpu_if)
{
- struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
- u64 used_lrs = vcpu->arch.vgic_cpu.used_lrs;
+ u64 used_lrs = cpu_if->used_lrs;
int i;
if (used_lrs || cpu_if->its_vpe.its_vm) {
@@ -257,10 +255,8 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
}
}
-void __hyp_text __vgic_v3_activate_traps(struct kvm_vcpu *vcpu)
+void __hyp_text __vgic_v3_activate_traps(struct vgic_v3_cpu_if *cpu_if)
{
- struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
-
/*
* VFIQEn is RES1 if ICC_SRE_EL1.SRE is 1. This causes a
* Group0 interrupt (as generated in GICv2 mode) to be
@@ -306,9 +302,8 @@ void __hyp_text __vgic_v3_activate_traps(struct kvm_vcpu *vcpu)
write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
}
-void __hyp_text __vgic_v3_deactivate_traps(struct kvm_vcpu *vcpu)
+void __hyp_text __vgic_v3_deactivate_traps(struct vgic_v3_cpu_if *cpu_if)
{
- struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
u64 val;
if (!cpu_if->vgic_sre) {
@@ -333,15 +328,11 @@ void __hyp_text __vgic_v3_deactivate_traps(struct kvm_vcpu *vcpu)
write_gicreg(0, ICH_HCR_EL2);
}
-void __hyp_text __vgic_v3_save_aprs(struct kvm_vcpu *vcpu)
+void __hyp_text __vgic_v3_save_aprs(struct vgic_v3_cpu_if *cpu_if)
{
- struct vgic_v3_cpu_if *cpu_if;
u64 val;
u32 nr_pre_bits;
- vcpu = kern_hyp_va(vcpu);
- cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
-
val = read_gicreg(ICH_VTR_EL2);
nr_pre_bits = vtr_to_nr_pre_bits(val);
@@ -370,15 +361,11 @@ void __hyp_text __vgic_v3_save_aprs(struct kvm_vcpu *vcpu)
}
}
-void __hyp_text __vgic_v3_restore_aprs(struct kvm_vcpu *vcpu)
+void __hyp_text __vgic_v3_restore_aprs(struct vgic_v3_cpu_if *cpu_if)
{
- struct vgic_v3_cpu_if *cpu_if;
u64 val;
u32 nr_pre_bits;
- vcpu = kern_hyp_va(vcpu);
- cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
-
val = read_gicreg(ICH_VTR_EL2);
nr_pre_bits = vtr_to_nr_pre_bits(val);
@@ -451,7 +438,7 @@ static int __hyp_text __vgic_v3_highest_priority_lr(struct kvm_vcpu *vcpu,
u32 vmcr,
u64 *lr_val)
{
- unsigned int used_lrs = vcpu->arch.vgic_cpu.used_lrs;
+ unsigned int used_lrs = vcpu->arch.vgic_cpu.vgic_v3.used_lrs;
u8 priority = GICv3_IDLE_PRIORITY;
int i, lr = -1;
@@ -490,7 +477,7 @@ static int __hyp_text __vgic_v3_highest_priority_lr(struct kvm_vcpu *vcpu,
static int __hyp_text __vgic_v3_find_active_lr(struct kvm_vcpu *vcpu,
int intid, u64 *lr_val)
{
- unsigned int used_lrs = vcpu->arch.vgic_cpu.used_lrs;
+ unsigned int used_lrs = vcpu->arch.vgic_cpu.vgic_v3.used_lrs;
int i;
for (i = 0; i < used_lrs; i++) {
diff --git a/arch/arm64/kvm/vgic/vgic-v2.c b/arch/arm64/kvm/vgic/vgic-v2.c
index 621cc168fe3f..ebf53a4e1296 100644
--- a/arch/arm64/kvm/vgic/vgic-v2.c
+++ b/arch/arm64/kvm/vgic/vgic-v2.c
@@ -56,7 +56,7 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu)
cpuif->vgic_hcr &= ~GICH_HCR_UIE;
- for (lr = 0; lr < vgic_cpu->used_lrs; lr++) {
+ for (lr = 0; lr < vgic_cpu->vgic_v2.used_lrs; lr++) {
u32 val = cpuif->vgic_lr[lr];
u32 cpuid, intid = val & GICH_LR_VIRTUALID;
struct vgic_irq *irq;
@@ -120,7 +120,7 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu)
vgic_put_irq(vcpu->kvm, irq);
}
- vgic_cpu->used_lrs = 0;
+ cpuif->used_lrs = 0;
}
/*
@@ -427,7 +427,7 @@ int vgic_v2_probe(const struct gic_kvm_info *info)
static void save_lrs(struct kvm_vcpu *vcpu, void __iomem *base)
{
struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
- u64 used_lrs = vcpu->arch.vgic_cpu.used_lrs;
+ u64 used_lrs = cpu_if->used_lrs;
u64 elrsr;
int i;
@@ -448,7 +448,7 @@ static void save_lrs(struct kvm_vcpu *vcpu, void __iomem *base)
void vgic_v2_save_state(struct kvm_vcpu *vcpu)
{
void __iomem *base = kvm_vgic_global_state.vctrl_base;
- u64 used_lrs = vcpu->arch.vgic_cpu.used_lrs;
+ u64 used_lrs = vcpu->arch.vgic_cpu.vgic_v2.used_lrs;
if (!base)
return;
@@ -463,7 +463,7 @@ void vgic_v2_restore_state(struct kvm_vcpu *vcpu)
{
struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
void __iomem *base = kvm_vgic_global_state.vctrl_base;
- u64 used_lrs = vcpu->arch.vgic_cpu.used_lrs;
+ u64 used_lrs = cpu_if->used_lrs;
int i;
if (!base)
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 3ccd6d3cb4d3..76e2d85789ed 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -39,7 +39,7 @@ void vgic_v3_fold_lr_state(struct kvm_vcpu *vcpu)
cpuif->vgic_hcr &= ~ICH_HCR_UIE;
- for (lr = 0; lr < vgic_cpu->used_lrs; lr++) {
+ for (lr = 0; lr < cpuif->used_lrs; lr++) {
u64 val = cpuif->vgic_lr[lr];
u32 intid, cpuid;
struct vgic_irq *irq;
@@ -111,7 +111,7 @@ void vgic_v3_fold_lr_state(struct kvm_vcpu *vcpu)
vgic_put_irq(vcpu->kvm, irq);
}
- vgic_cpu->used_lrs = 0;
+ cpuif->used_lrs = 0;
}
/* Requires the irq to be locked already */
@@ -662,10 +662,10 @@ void vgic_v3_load(struct kvm_vcpu *vcpu)
if (likely(cpu_if->vgic_sre))
kvm_call_hyp(__vgic_v3_write_vmcr, cpu_if->vgic_vmcr);
- kvm_call_hyp(__vgic_v3_restore_aprs, vcpu);
+ kvm_call_hyp(__vgic_v3_restore_aprs, kern_hyp_va(cpu_if));
if (has_vhe())
- __vgic_v3_activate_traps(vcpu);
+ __vgic_v3_activate_traps(cpu_if);
WARN_ON(vgic_v4_load(vcpu));
}
@@ -680,12 +680,14 @@ void vgic_v3_vmcr_sync(struct kvm_vcpu *vcpu)
void vgic_v3_put(struct kvm_vcpu *vcpu)
{
+ struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
+
WARN_ON(vgic_v4_put(vcpu, false));
vgic_v3_vmcr_sync(vcpu);
- kvm_call_hyp(__vgic_v3_save_aprs, vcpu);
+ kvm_call_hyp(__vgic_v3_save_aprs, kern_hyp_va(cpu_if));
if (has_vhe())
- __vgic_v3_deactivate_traps(vcpu);
+ __vgic_v3_deactivate_traps(cpu_if);
}
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 99b02ca730a8..c3643b7f101b 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -786,6 +786,7 @@ static void vgic_flush_lr_state(struct kvm_vcpu *vcpu)
int count;
bool multi_sgi;
u8 prio = 0xff;
+ int i = 0;
lockdep_assert_held(&vgic_cpu->ap_list_lock);
@@ -827,11 +828,14 @@ static void vgic_flush_lr_state(struct kvm_vcpu *vcpu)
}
}
- vcpu->arch.vgic_cpu.used_lrs = count;
-
/* Nuke remaining LRs */
- for ( ; count < kvm_vgic_global_state.nr_lr; count++)
- vgic_clear_lr(vcpu, count);
+ for (i = count ; i < kvm_vgic_global_state.nr_lr; i++)
+ vgic_clear_lr(vcpu, i);
+
+ if (!static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
+ vcpu->arch.vgic_cpu.vgic_v2.used_lrs = count;
+ else
+ vcpu->arch.vgic_cpu.vgic_v3.used_lrs = count;
}
static inline bool can_access_vgic_from_kernel(void)
@@ -849,13 +853,13 @@ static inline void vgic_save_state(struct kvm_vcpu *vcpu)
if (!static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
vgic_v2_save_state(vcpu);
else
- __vgic_v3_save_state(vcpu);
+ __vgic_v3_save_state(&vcpu->arch.vgic_cpu.vgic_v3);
}
/* Sync back the hardware VGIC state into our emulation after a guest's run. */
void kvm_vgic_sync_hwstate(struct kvm_vcpu *vcpu)
{
- struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
+ int used_lrs;
/* An empty ap_list_head implies used_lrs == 0 */
if (list_empty(&vcpu->arch.vgic_cpu.ap_list_head))
@@ -864,7 +868,12 @@ void kvm_vgic_sync_hwstate(struct kvm_vcpu *vcpu)
if (can_access_vgic_from_kernel())
vgic_save_state(vcpu);
- if (vgic_cpu->used_lrs)
+ if (!static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
+ used_lrs = vcpu->arch.vgic_cpu.vgic_v2.used_lrs;
+ else
+ used_lrs = vcpu->arch.vgic_cpu.vgic_v3.used_lrs;
+
+ if (used_lrs)
vgic_fold_lr_state(vcpu);
vgic_prune_ap_list(vcpu);
}
@@ -874,7 +883,7 @@ static inline void vgic_restore_state(struct kvm_vcpu *vcpu)
if (!static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
vgic_v2_restore_state(vcpu);
else
- __vgic_v3_restore_state(vcpu);
+ __vgic_v3_restore_state(&vcpu->arch.vgic_cpu.vgic_v3);
}
/* Flush our emulation state into the GIC hardware before entering the guest. */
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 69f4164d6477..a8d8fdcd3723 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -274,6 +274,8 @@ struct vgic_v2_cpu_if {
u32 vgic_vmcr;
u32 vgic_apr;
u32 vgic_lr[VGIC_V2_MAX_LRS];
+
+ unsigned int used_lrs;
};
struct vgic_v3_cpu_if {
@@ -291,6 +293,8 @@ struct vgic_v3_cpu_if {
* linking the Linux IRQ subsystem and the ITS together.
*/
struct its_vpe its_vpe;
+
+ unsigned int used_lrs;
};
struct vgic_cpu {
@@ -300,7 +304,6 @@ struct vgic_cpu {
struct vgic_v3_cpu_if vgic_v3;
};
- unsigned int used_lrs;
struct vgic_irq private_irqs[VGIC_NR_PRIVATE_IRQS];
raw_spinlock_t ap_list_lock; /* Protects the ap_list */
--
2.26.2
_______________________________________________
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 11/24] KVM: arm64: Clean up the checking for huge mapping
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
If we are checking whether the stage2 can map PAGE_SIZE,
we don't have to do the boundary checks as both the host
VMA and the guest memslots are page aligned. Bail the case
easily.
While we're at it, fixup a typo in the comment below.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200507123546.1875-2-yuzenghui@huawei.com
---
arch/arm64/kvm/mmu.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 917363375e8a..ccb44e7d30d9 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1610,6 +1610,10 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
hva_t uaddr_start, uaddr_end;
size_t size;
+ /* The memslot and the VMA are guaranteed to be aligned to PAGE_SIZE */
+ if (map_size == PAGE_SIZE)
+ return true;
+
size = memslot->npages * PAGE_SIZE;
gpa_start = memslot->base_gfn << PAGE_SHIFT;
@@ -1629,7 +1633,7 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
* |abcde|fgh Stage-1 block | Stage-1 block tv|xyz|
* +-----+--------------------+--------------------+---+
*
- * memslot->base_gfn << PAGE_SIZE:
+ * memslot->base_gfn << PAGE_SHIFT:
* +---+--------------------+--------------------+-----+
* |abc|def Stage-2 block | Stage-2 block |tvxyz|
* +---+--------------------+--------------------+-----+
--
2.26.2
_______________________________________________
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 23/24] KVM: arm64: Parametrize exception entry with a target EL
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
We currently assume that an exception is delivered to EL1, always.
Once we emulate EL2, this no longer will be the case. To prepare
for this, add a target_mode parameter.
While we're at it, merge the computing of the target PC and PSTATE in
a single function that updates both PC and CPSR after saving their
previous values in the corresponding ELR/SPSR. This ensures that they
are updated in the correct order (a pretty common source of bugs...).
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/include/asm/ptrace.h | 1 +
arch/arm64/kvm/inject_fault.c | 75 +++++++++++++++++----------------
2 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index bf57308fcd63..953b6a1ce549 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -35,6 +35,7 @@
#define GIC_PRIO_PSR_I_SET (1 << 4)
/* Additional SPSR bits not exposed in the UABI */
+#define PSR_MODE_THREAD_BIT (1 << 0)
#define PSR_IL_BIT (1 << 20)
/* AArch32-specific ptrace requests */
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 6aafc2825c1c..e21fdd93027a 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -26,28 +26,12 @@ enum exception_type {
except_type_serror = 0x180,
};
-static u64 get_except_vector(struct kvm_vcpu *vcpu, enum exception_type type)
-{
- u64 exc_offset;
-
- switch (*vcpu_cpsr(vcpu) & (PSR_MODE_MASK | PSR_MODE32_BIT)) {
- case PSR_MODE_EL1t:
- exc_offset = CURRENT_EL_SP_EL0_VECTOR;
- break;
- case PSR_MODE_EL1h:
- exc_offset = CURRENT_EL_SP_ELx_VECTOR;
- break;
- case PSR_MODE_EL0t:
- exc_offset = LOWER_EL_AArch64_VECTOR;
- break;
- default:
- exc_offset = LOWER_EL_AArch32_VECTOR;
- }
-
- return vcpu_read_sys_reg(vcpu, VBAR_EL1) + exc_offset + type;
-}
-
/*
+ * This performs the exception entry at a given EL (@target_mode), stashing PC
+ * and PSTATE into ELR and SPSR respectively, and compute the new PC/PSTATE.
+ * The EL passed to this function *must* be a non-secure, privileged mode with
+ * bit 0 being set (PSTATE.SP == 1).
+ *
* When an exception is taken, most PSTATE fields are left unchanged in the
* handler. However, some are explicitly overridden (e.g. M[4:0]). Luckily all
* of the inherited bits have the same position in the AArch64/AArch32 SPSR_ELx
@@ -59,10 +43,35 @@ static u64 get_except_vector(struct kvm_vcpu *vcpu, enum exception_type type)
* Here we manipulate the fields in order of the AArch64 SPSR_ELx layout, from
* MSB to LSB.
*/
-static unsigned long get_except64_pstate(struct kvm_vcpu *vcpu)
+static void enter_exception64(struct kvm_vcpu *vcpu, unsigned long target_mode,
+ enum exception_type type)
{
- unsigned long sctlr = vcpu_read_sys_reg(vcpu, SCTLR_EL1);
- unsigned long old, new;
+ unsigned long sctlr, vbar, old, new, mode;
+ u64 exc_offset;
+
+ mode = *vcpu_cpsr(vcpu) & (PSR_MODE_MASK | PSR_MODE32_BIT);
+
+ if (mode == target_mode)
+ exc_offset = CURRENT_EL_SP_ELx_VECTOR;
+ else if ((mode | PSR_MODE_THREAD_BIT) == target_mode)
+ exc_offset = CURRENT_EL_SP_EL0_VECTOR;
+ else if (!(mode & PSR_MODE32_BIT))
+ exc_offset = LOWER_EL_AArch64_VECTOR;
+ else
+ exc_offset = LOWER_EL_AArch32_VECTOR;
+
+ switch (target_mode) {
+ case PSR_MODE_EL1h:
+ vbar = vcpu_read_sys_reg(vcpu, VBAR_EL1);
+ sctlr = vcpu_read_sys_reg(vcpu, SCTLR_EL1);
+ vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
+ break;
+ default:
+ /* Don't do that */
+ BUG();
+ }
+
+ *vcpu_pc(vcpu) = vbar + exc_offset + type;
old = *vcpu_cpsr(vcpu);
new = 0;
@@ -105,9 +114,10 @@ static unsigned long get_except64_pstate(struct kvm_vcpu *vcpu)
new |= PSR_I_BIT;
new |= PSR_F_BIT;
- new |= PSR_MODE_EL1h;
+ new |= target_mode;
- return new;
+ *vcpu_cpsr(vcpu) = new;
+ vcpu_write_spsr(vcpu, old);
}
static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr)
@@ -116,11 +126,7 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr
bool is_aarch32 = vcpu_mode_is_32bit(vcpu);
u32 esr = 0;
- vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
- *vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
-
- *vcpu_cpsr(vcpu) = get_except64_pstate(vcpu);
- vcpu_write_spsr(vcpu, cpsr);
+ enter_exception64(vcpu, PSR_MODE_EL1h, except_type_sync);
vcpu_write_sys_reg(vcpu, addr, FAR_EL1);
@@ -148,14 +154,9 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr
static void inject_undef64(struct kvm_vcpu *vcpu)
{
- unsigned long cpsr = *vcpu_cpsr(vcpu);
u32 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
- vcpu_write_elr_el1(vcpu, *vcpu_pc(vcpu));
- *vcpu_pc(vcpu) = get_except_vector(vcpu, except_type_sync);
-
- *vcpu_cpsr(vcpu) = get_except64_pstate(vcpu);
- vcpu_write_spsr(vcpu, cpsr);
+ enter_exception64(vcpu, PSR_MODE_EL1h, except_type_sync);
/*
* Build an unknown exception, depending on the instruction
--
2.26.2
_______________________________________________
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 16/24] KVM: arm64: Fix incorrect comment on kvm_get_hyp_vector()
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: David Brazdil <dbrazdil@google.com>
The comment used to say that kvm_get_hyp_vector is only called on VHE systems.
In fact, it is also called from the nVHE init function cpu_init_hyp_mode().
Fix the comment to stop confusing devs.
Signed-off-by: David Brazdil <dbrazdil@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200515152550.83810-1-dbrazdil@google.com
---
arch/arm64/include/asm/kvm_mmu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 30b0e8d6b895..796f6a2e794a 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -473,7 +473,7 @@ static inline int kvm_write_guest_lock(struct kvm *kvm, gpa_t gpa,
extern void *__kvm_bp_vect_base;
extern int __kvm_harden_el2_vector_slot;
-/* This is only called on a VHE system */
+/* This is called on both VHE and !VHE systems */
static inline void *kvm_get_hyp_vector(void)
{
struct bp_hardening_data *data = arm64_get_bp_hardening_data();
--
2.26.2
_______________________________________________
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 22/24] KVM: arm64: Don't use empty structures as CPU reset state
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
Keeping empty structure as the vcpu state initializer is slightly
wasteful: we only want to set pstate, and zero everything else.
Just do that.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/reset.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 658f3a79617b..865c8aa670bc 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -36,15 +36,11 @@ static u32 kvm_ipa_limit;
/*
* ARMv8 Reset Values
*/
-static const struct kvm_regs default_regs_reset = {
- .regs.pstate = (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT |
- PSR_F_BIT | PSR_D_BIT),
-};
+#define VCPU_RESET_PSTATE_EL1 (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | \
+ PSR_F_BIT | PSR_D_BIT)
-static const struct kvm_regs default_regs_reset32 = {
- .regs.pstate = (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT |
- PSR_AA32_I_BIT | PSR_AA32_F_BIT),
-};
+#define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
+ PSR_AA32_I_BIT | PSR_AA32_F_BIT)
static bool cpu_has_32bit_el1(void)
{
@@ -257,9 +253,9 @@ static int kvm_vcpu_enable_ptrauth(struct kvm_vcpu *vcpu)
*/
int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
{
- const struct kvm_regs *cpu_reset;
int ret = -EINVAL;
bool loaded;
+ u32 pstate;
/* Reset PMU outside of the non-preemptible section */
kvm_pmu_vcpu_reset(vcpu);
@@ -290,16 +286,17 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
if (!cpu_has_32bit_el1())
goto out;
- cpu_reset = &default_regs_reset32;
+ pstate = VCPU_RESET_PSTATE_SVC;
} else {
- cpu_reset = &default_regs_reset;
+ pstate = VCPU_RESET_PSTATE_EL1;
}
break;
}
/* Reset core registers */
- memcpy(vcpu_gp_regs(vcpu), cpu_reset, sizeof(*cpu_reset));
+ memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
+ vcpu_gp_regs(vcpu)->regs.pstate = pstate;
/* Reset system registers */
kvm_reset_sys_regs(vcpu);
--
2.26.2
_______________________________________________
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 12/24] KVM: arm64: Unify handling THP backed host memory
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
We support mapping host memory backed by PMD transparent hugepages
at stage2 as huge pages. However the checks are now spread across
two different places. Let us unify the handling of the THPs to
keep the code cleaner (and future proof for PUD THP support).
This patch moves transparent_hugepage_adjust() closer to the caller
to avoid a forward declaration for fault_supports_stage2_huge_mappings().
Also, since we already handle the case where the host VA and the guest
PA may not be aligned, the explicit VM_BUG_ON() is not required.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200507123546.1875-3-yuzenghui@huawei.com
---
arch/arm64/kvm/mmu.c | 115 ++++++++++++++++++++++---------------------
1 file changed, 60 insertions(+), 55 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index ccb44e7d30d9..66eb8e3f6e8c 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1375,47 +1375,6 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
return ret;
}
-static bool transparent_hugepage_adjust(kvm_pfn_t *pfnp, phys_addr_t *ipap)
-{
- kvm_pfn_t pfn = *pfnp;
- gfn_t gfn = *ipap >> PAGE_SHIFT;
-
- if (kvm_is_transparent_hugepage(pfn)) {
- unsigned long mask;
- /*
- * The address we faulted on is backed by a transparent huge
- * page. However, because we map the compound huge page and
- * not the individual tail page, we need to transfer the
- * refcount to the head page. We have to be careful that the
- * THP doesn't start to split while we are adjusting the
- * refcounts.
- *
- * We are sure this doesn't happen, because mmu_notifier_retry
- * was successful and we are holding the mmu_lock, so if this
- * THP is trying to split, it will be blocked in the mmu
- * notifier before touching any of the pages, specifically
- * before being able to call __split_huge_page_refcount().
- *
- * We can therefore safely transfer the refcount from PG_tail
- * to PG_head and switch the pfn from a tail page to the head
- * page accordingly.
- */
- mask = PTRS_PER_PMD - 1;
- VM_BUG_ON((gfn & mask) != (pfn & mask));
- if (pfn & mask) {
- *ipap &= PMD_MASK;
- kvm_release_pfn_clean(pfn);
- pfn &= ~mask;
- kvm_get_pfn(pfn);
- *pfnp = pfn;
- }
-
- return true;
- }
-
- return false;
-}
-
/**
* stage2_wp_ptes - write protect PMD range
* @pmd: pointer to pmd entry
@@ -1663,6 +1622,59 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
(hva & ~(map_size - 1)) + map_size <= uaddr_end;
}
+/*
+ * Check if the given hva is backed by a transparent huge page (THP) and
+ * whether it can be mapped using block mapping in stage2. If so, adjust
+ * the stage2 PFN and IPA accordingly. Only PMD_SIZE THPs are currently
+ * supported. This will need to be updated to support other THP sizes.
+ *
+ * Returns the size of the mapping.
+ */
+static unsigned long
+transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
+ unsigned long hva, kvm_pfn_t *pfnp,
+ phys_addr_t *ipap)
+{
+ kvm_pfn_t pfn = *pfnp;
+
+ /*
+ * Make sure the adjustment is done only for THP pages. Also make
+ * sure that the HVA and IPA are sufficiently aligned and that the
+ * block map is contained within the memslot.
+ */
+ if (kvm_is_transparent_hugepage(pfn) &&
+ fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE)) {
+ /*
+ * The address we faulted on is backed by a transparent huge
+ * page. However, because we map the compound huge page and
+ * not the individual tail page, we need to transfer the
+ * refcount to the head page. We have to be careful that the
+ * THP doesn't start to split while we are adjusting the
+ * refcounts.
+ *
+ * We are sure this doesn't happen, because mmu_notifier_retry
+ * was successful and we are holding the mmu_lock, so if this
+ * THP is trying to split, it will be blocked in the mmu
+ * notifier before touching any of the pages, specifically
+ * before being able to call __split_huge_page_refcount().
+ *
+ * We can therefore safely transfer the refcount from PG_tail
+ * to PG_head and switch the pfn from a tail page to the head
+ * page accordingly.
+ */
+ *ipap &= PMD_MASK;
+ kvm_release_pfn_clean(pfn);
+ pfn &= ~(PTRS_PER_PMD - 1);
+ kvm_get_pfn(pfn);
+ *pfnp = pfn;
+
+ return PMD_SIZE;
+ }
+
+ /* Use page mapping if we cannot use block mapping. */
+ return PAGE_SIZE;
+}
+
static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
struct kvm_memory_slot *memslot, unsigned long hva,
unsigned long fault_status)
@@ -1776,20 +1788,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (mmu_notifier_retry(kvm, mmu_seq))
goto out_unlock;
- if (vma_pagesize == PAGE_SIZE && !force_pte) {
- /*
- * Only PMD_SIZE transparent hugepages(THP) are
- * currently supported. This code will need to be
- * updated to support other THP sizes.
- *
- * Make sure the host VA and the guest IPA are sufficiently
- * aligned and that the block is contained within the memslot.
- */
- if (fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE) &&
- transparent_hugepage_adjust(&pfn, &fault_ipa))
- vma_pagesize = PMD_SIZE;
- }
-
+ /*
+ * If we are not forced to use page mapping, check if we are
+ * backed by a THP and thus use block mapping if possible.
+ */
+ if (vma_pagesize == PAGE_SIZE && !force_pte)
+ vma_pagesize = transparent_hugepage_adjust(memslot, hva,
+ &pfn, &fault_ipa);
if (writable)
kvm_set_pfn_dirty(pfn);
--
2.26.2
_______________________________________________
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 13/24] KVM: arm64: Support enabling dirty log gradually in small chunks
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Keqian Zhu <zhukeqian1@huawei.com>
There is already support of enabling dirty log gradually in small chunks
for x86 in commit 3c9bd4006bfc ("KVM: x86: enable dirty log gradually in
small chunks"). This adds support for arm64.
x86 still writes protect all huge pages when DIRTY_LOG_INITIALLY_ALL_SET
is enabled. However, for arm64, both huge pages and normal pages can be
write protected gradually by userspace.
Under the Huawei Kunpeng 920 2.6GHz platform, I did some tests on 128G
Linux VMs with different page size. The memory pressure is 127G in each
case. The time taken of memory_global_dirty_log_start in QEMU is listed
below:
Page Size Before After Optimization
4K 650ms 1.8ms
2M 4ms 1.8ms
1G 2ms 1.8ms
Besides the time reduction, the biggest improvement is that we will minimize
the performance side effect (because of dissolving huge pages and marking
memslots dirty) on guest after enabling dirty log.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200413122023.52583-1-zhukeqian1@huawei.com
---
Documentation/virt/kvm/api.rst | 2 +-
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/kvm/mmu.c | 12 ++++++++++--
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index efbbe570aa9b..0017f63fa44f 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -5777,7 +5777,7 @@ will be initialized to 1 when created. This also improves performance because
dirty logging can be enabled gradually in small chunks on the first call
to KVM_CLEAR_DIRTY_LOG. KVM_DIRTY_LOG_INITIALLY_SET depends on
KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE (it is also only available on
-x86 for now).
+x86 and arm64 for now).
KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 was previously available under the name
KVM_CAP_MANUAL_DIRTY_LOG_PROTECT, but the implementation had bugs that make
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 32c8a675e5a4..a723f84fab83 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -46,6 +46,9 @@
#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
#define KVM_REQ_RELOAD_GICv4 KVM_ARCH_REQ(4)
+#define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
+ KVM_DIRTY_LOG_INITIALLY_SET)
+
DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
extern unsigned int kvm_sve_max_vl;
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 66eb8e3f6e8c..ddf85bf21897 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2277,8 +2277,16 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
* allocated dirty_bitmap[], dirty pages will be tracked while the
* memory slot is write protected.
*/
- if (change != KVM_MR_DELETE && mem->flags & KVM_MEM_LOG_DIRTY_PAGES)
- kvm_mmu_wp_memory_region(kvm, mem->slot);
+ if (change != KVM_MR_DELETE && mem->flags & KVM_MEM_LOG_DIRTY_PAGES) {
+ /*
+ * If we're with initial-all-set, we don't need to write
+ * protect any pages because they're all reported as dirty.
+ * Huge pages and normal pages will be write protect gradually.
+ */
+ if (!kvm_dirty_log_manual_protect_and_init_set(kvm)) {
+ kvm_mmu_wp_memory_region(kvm, mem->slot);
+ }
+ }
}
int kvm_arch_prepare_memory_region(struct kvm *kvm,
--
2.26.2
_______________________________________________
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 10/24] KVM: arm/arm64: Release kvm->mmu_lock in loop to prevent starvation
From: Marc Zyngier @ 2020-05-29 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Mark Rutland, kvmarm, kvm, Will Deacon, Suzuki K Poulose,
Keqian Zhu, Christoffer Dall, Jiang Yi, James Morse, Andrew Scull,
Zenghui Yu, Julien Thierry, David Brazdil, Alexandru Elisei,
Ard Biesheuvel, Fuad Tabba, linux-arm-kernel
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Jiang Yi <giangyi@amazon.com>
Do cond_resched_lock() in stage2_flush_memslot() like what is done in
unmap_stage2_range() and other places holding mmu_lock while processing
a possibly large range of memory.
Signed-off-by: Jiang Yi <giangyi@amazon.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20200415084229.29992-1-giangyi@amazon.com
---
arch/arm64/kvm/mmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 29d8f24df944..917363375e8a 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -422,6 +422,9 @@ static void stage2_flush_memslot(struct kvm *kvm,
next = stage2_pgd_addr_end(kvm, addr, end);
if (!stage2_pgd_none(kvm, *pgd))
stage2_flush_puds(kvm, pgd, addr, next);
+
+ if (next != end)
+ cond_resched_lock(&kvm->mmu_lock);
} while (pgd++, addr = next, addr != end);
}
--
2.26.2
_______________________________________________
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 v4 04/11] thermal: Store device mode in struct thermal_zone_device
From: Andrzej Pietrasiewicz @ 2020-05-29 16:08 UTC (permalink / raw)
To: Guenter Roeck
Cc: Emmanuel Grumbach, Heiko Stuebner, Kalle Valo, linux-wireless,
Peter Kaestle, platform-driver-x86, Vishal Kulkarni, Luca Coelho,
Miquel Raynal, Shawn Guo, kernel, Fabio Estevam, Amit Kucheria,
linux-rockchip, Chunyan Zhang, Daniel Lezcano, linux-acpi,
linux-arm-kernel, Darren Hart, Zhang Rui, Gayatri Kammela,
NXP Linux Team, Johannes Berg, linux-pm, Sascha Hauer,
Intel Linux Wireless, Ido Schimmel, Niklas Söderlund,
Jiri Pirko, Orson Zhai, Thomas Gleixner, Allison Randal,
Support Opensource, netdev, Rafael J . Wysocki, Sebastian Reichel,
linux-renesas-soc, Bartlomiej Zolnierkiewicz,
Pengutronix Kernel Team, Baolin Wang, Len Brown, Enrico Weigelt,
David S . Miller, Andy Shevchenko
In-Reply-To: <20200529154205.GA157653@roeck-us.net>
Hi Guenter,
W dniu 29.05.2020 o 17:42, Guenter Roeck pisze:
> On Thu, May 28, 2020 at 09:20:44PM +0200, Andrzej Pietrasiewicz wrote:
>> Prepare for eliminating get_mode().
>>
> Might be worthwhile to explain (not only in the subject) what you are
> doing here.
>
>> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
>> ---
>> drivers/acpi/thermal.c | 18 ++++++----------
>> .../ethernet/mellanox/mlxsw/core_thermal.c | 21 +++++++------------
>> drivers/platform/x86/acerhdf.c | 15 ++++++-------
>> drivers/thermal/da9062-thermal.c | 6 ++----
>> drivers/thermal/imx_thermal.c | 17 +++++++--------
>> .../intel/int340x_thermal/int3400_thermal.c | 12 +++--------
>> .../thermal/intel/intel_quark_dts_thermal.c | 16 +++++++-------
>> drivers/thermal/thermal_of.c | 10 +++------
>
> After this patch is applied on top of the thermal 'testing' branch,
> there are still local instances of thermal_device_mode in
> drivers/thermal/st/stm_thermal.c
> drivers/thermal/ti-soc-thermal/ti-thermal-common.c
>
> If there is a reason not to replace those, it might make sense to explain
> it here.
>
My understanding is that these two are sensor devices which are "plugged"
into their "parent" thermal zone device. The latter is the "proper" tzd.
They both use thermal_zone_of_device_ops instead of thermal_zone_device_ops.
The former doesn't even have get_mode(). The thermal core, when it calls
get_mode(), operates on the "parent" thermal zone devices.
Consequently, the drivers you mention use their "mode" members for
their private purpose, not for the purpose of storing the "parent"
thermal zone device mode.
Andrzej
_______________________________________________
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 v8 5/5] dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
From: James Morse @ 2020-05-29 16:11 UTC (permalink / raw)
To: Rob Herring, chenzhou
Cc: Simon Horman, John.p.donnelly, Baoquan He, Will Deacon,
devicetree, Catalin Marinas, Linux Doc Mailing List, kexec,
linux-kernel@vger.kernel.org, Ingo Molnar, Arnd Bergmann,
Hanjun Guo, Thomas Gleixner, pkushwaha, dyoung,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200526211800.GA352001@bogus>
Hi guys,
On 26/05/2020 22:18, Rob Herring wrote:
> On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
>> On 2020/5/21 21:29, Rob Herring wrote:
>>> On Thu, May 21, 2020 at 3:35 AM Chen Zhou <chenzhou10@huawei.com> wrote:
>>>> Add documentation for DT property used by arm64 kdump:
>>>> linux,low-memory-range.
>>>> "linux,low-memory-range" is an another memory region used for crash
>>>> dump kernel devices.
>>>> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
>>>> index 45e79172a646..bfe6fb6976e6 100644
>>>> --- a/Documentation/devicetree/bindings/chosen.txt
>>>> +++ b/Documentation/devicetree/bindings/chosen.txt
>>>> +linux,low-memory-range
>>>> +----------------------
>>>> +This property (arm64 only) holds a base address and size, describing a
>>>> +limited region below 4G. Similar to "linux,usable-memory-range", it is
>>>> +an another memory range which may be considered available for use by the
>>>> +kernel.
>>> Why can't you just add a range to "linux,usable-memory-range"? It
>>> shouldn't be hard to figure out which part is below 4G.
>> The comments from James:
>> Won't this break if your kdump kernel doesn't know what the extra parameters are?
>> Or if it expects two ranges, but only gets one? These DT properties should be treated as
>> ABI between kernel versions, we can't really change it like this.
>>
>> I think the 'low' region is an optional-extra, that is never mapped by the first kernel. I
>> think the simplest thing to do is to add an 'linux,low-memory-range' that we
>> memblock_add() after memblock_cap_memory_range() has been called.
>> If its missing, or the new kernel doesn't know what its for, everything keeps working.
>
>
> I don't think there's a compatibility issue here though. The current
> kernel doesn't care if the property is longer than 1 base+size. It only
> checks if the size is less than 1 base+size.
Aha! I missed that.
> And yes, we can rely on
> that implementation detail. It's only an ABI if an existing user
> notices.
>
> Now, if the low memory is listed first, then an older kdump kernel
> would get a different memory range. If that's a problem, then define
> that low memory goes last.
This first entry would need to be the 'crashkernel' range where the kdump kernel is
placed, otherwise an older kernel won't boot. The rest can be optional extras, as long as
we are tolerant of it being missing...
I'll try and look at the rest of this series on Monday,
Thanks,
James
_______________________________________________
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 1/3] media: dt-bindings: media: Document Rockchip CIF bindings
From: Rob Herring @ 2020-05-29 16:14 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Mark Rutland, devicetree, Heiko Stuebner, linux-kernel,
Paul Kocialkowski, linux-rockchip, Rob Herring, Thomas Petazzoni,
Miquel Raynal, Hans Verkuil, Mauro Carvalho Chehab, Robin Murphy,
linux-arm-kernel, linux-media
In-Reply-To: <20200529130405.929429-2-maxime.chevallier@bootlin.com>
On Fri, 29 May 2020 15:04:03 +0200, Maxime Chevallier wrote:
> Add a documentation for the Rockchip Camera Interface controller
> binding.
>
> This controller can be found on platforms such as the PX30 or the
> RK3288, the PX30 being the only platform supported so far.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>
> Changes since V1
>
> - Updated the clock and reset names
> - Added missing includes in the example, so that the make dt_binding_check passes
>
> .../bindings/media/rockchip-cif.yaml | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: Additional items are not allowed ('cif_out' was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:0: 'aclk' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:1: 'hclkf' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:2: 'pclkin' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: ['aclk_cif', 'hclk_cif', 'pclk_cif', 'cif_out'] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: Additional items are not allowed ([4294967295, 52] was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: [[4294967295, 179], [4294967295, 249], [4294967295, 352], [4294967295, 52]] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:0: 'axi' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:1: 'ahb' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:2: 'pclkin' was expected
See https://patchwork.ozlabs.org/patch/1300680
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
_______________________________________________
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 v6 4/9] dt-bindings: display: panel: Add ilitek ili9341 panel bindings
From: Rob Herring @ 2020-05-29 16:17 UTC (permalink / raw)
To: dillon.minfei
Cc: dillonhua, airlied, linus.walleij, dri-devel, thierry.reding, sam,
linux-stm32, linux-clk, andy.shevchenko, p.zabel, mturquette,
devicetree, alexandre.torgue, robh+dt, daniel, linux-arm-kernel,
sboyd, linux-kernel, linux-spi, noralf, broonie, mcoquelin.stm32
In-Reply-To: <1590564453-24499-5-git-send-email-dillon.minfei@gmail.com>
On Wed, 27 May 2020 15:27:28 +0800, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
>
> Add documentation for "ilitek,ili9341" panel.
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
> .../bindings/display/panel/ilitek,ili9341.yaml | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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 v8 0/8] Add support for devices in the Energy Model
From: Rafael J. Wysocki @ 2020-05-29 16:18 UTC (permalink / raw)
To: Lukasz Luba
Cc: Nishanth Menon, Juri Lelli, Peter Zijlstra, Viresh Kumar,
Liviu Dudau, dri-devel, Bjorn Andersson, Benjamin Segall,
alyssa.rosenzweig, Fabio Estevam, Matthias Kaehlcke, Rob Herring,
Amit Kucheria, Lorenzo Pieralisi, Kevin Hilman, Andy Gross,
Daniel Lezcano, steven.price, Chanwoo Choi, Ingo Molnar,
dl-linux-imx, Zhang, Rui, Mel Gorman, orjan.eide, Daniel Vetter,
Linux PM, linux-arm-msm, Sascha Hauer, Steven Rostedt,
moderated list:ARM/Mediatek SoC..., Matthias Brugger,
Linux OMAP Mailing List, Dietmar Eggemann, Linux ARM,
David Airlie, Tomeu Vizoso, Quentin Perret, Stephen Boyd,
Randy Dunlap, Rafael J. Wysocki, Linux Kernel Mailing List,
Bartlomiej Zolnierkiewicz, Sascha Hauer, Sudeep Holla,
patrick.bellasi, Shawn Guo
In-Reply-To: <8fca24a1-93f7-f859-bd1f-b7bf484737f4@arm.com>
On Fri, May 29, 2020 at 5:01 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi Rafael,
>
>
> On 5/27/20 10:58 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > Background of this version:
> > This is the v8 of the patch set and is has smaller scope. I had to split
> > the series into two: EM changes and thermal changes due to devfreq
> > dependencies. The patches from v7 9-14 which change devfreq cooling are
> > going to be sent in separate patch series, just after this set get merged
> > into mainline. These patches related to EM got acks and hopefully can go
> > through linux-pm tree. The later thermal patches will go through thermal
> > tree.
> >
> > The idea and purpose of the Energy Model framework changes:
> > This patch set introduces support for devices in the Energy Model (EM)
> > framework. It will unify the power model for thermal subsystem. It will
> > make simpler to add support for new devices willing to use more
> > advanced features (like Intelligent Power Allocation). Now it should
> > require less knowledge and effort for driver developer to add e.g.
> > GPU driver with simple energy model. A more sophisticated energy model
> > in the thermal framework is also possible, driver needs to provide
> > a dedicated callback function. More information can be found in the
> > updated documentation file.
> >
> > First 7 patches are refactoring Energy Model framework to add support
> > of other devices that CPUs. They change:
> > - naming convention from 'capacity' to 'performance' state,
> > - API arguments adding device pointer and not rely only on cpumask,
> > - change naming when 'cpu' was used, now it's a 'device'
> > - internal structure to maintain registered devices
> > - update users to the new API
> > Patch 8 updates OPP framework helper function to be more generic, not
> > CPU specific.
> >
> > The patch set is based on linux-pm branch linux-next 813946019dfd.
> >
>
> Could you take the patch set via your linux-pm?
I can do that, but I didn't realize that it was targeted at me, so I
need some more time to review the patches.
Thanks!
_______________________________________________
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 v7 0/3] perf arm-spe: Add support for synthetic events
From: Arnaldo Carvalho de Melo @ 2020-05-29 16:18 UTC (permalink / raw)
To: Leo Yan
Cc: Mark Rutland, Al Grant, Mathieu Poirier, Peter Zijlstra,
Will Deacon, linux-kernel, Alexander Shishkin, Ingo Molnar,
James Clark, Namhyung Kim, Jiri Olsa, linux-arm-kernel,
Mike Leach
In-Reply-To: <20200529152800.GB21552@leoy-ThinkPad-X240s>
Em Fri, May 29, 2020 at 11:28:01PM +0800, Leo Yan escreveu:
> Hi James,
>
> On Fri, May 29, 2020 at 03:58:23PM +0100, James Clark wrote:
> > Hi Will and Leo,
> >
> > I've tested this on an Arm N1 machine and it looks good to me.
>
> This is great! Will respin the new patch set with adding your test tag
> and send to ML. Thanks a lot for the effort.
>
> Hi Will, Arnaldo, sorry for late replying you due to other works and
> thanks for suggestions in other emails.
Np, please do it on top of my tmp.perf/core branch, it'll become
perf/core as soon as testing that is ongoing finishes.
- Arnaldo
_______________________________________________
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 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Serge Semin @ 2020-05-29 16:21 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, linux-kernel, Serge Semin, linux-spi, SoC Team,
Mark Brown, Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200513140031.25633-1-lars.povlsen@microchip.com>
Hello Lars,
On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
> This is an add-on series to the main SoC Sparx5 series
> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
>
> The series add support for Sparx5 on top of the existing
> ocelot/jaguar2 spi driver.
>
> It spins off the existing support for the MSCC platforms into a
> separate driver, as adding new platforms from the MSCC/Microchip
> product lines will further complicate (clutter) the original driver.
>
> New YAML dt-bindings are provided for the resulting driver.
>
> It is expected that the DT patches are to be taken directly by the arm-soc
> maintainers.
Regarding our cooperation. It can be implemented as follows. Since your patchset
is less cumbersome than mine and is more ready to be integrated into the generic DW
APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
to be further merged into the kernel version of the driver. After that I'll have
my code altered so it could be applied on top of your patches. When everything
is done we'll have a more comprehensive DW APB SSI driver with poll-based
PIO operations support, new features like rx-delay, etc.
Thank you one more time for the series you've shared with us. Let's see what can
be done to improve it...
-Sergey
>
> Lars Povlsen (10):
> spi: dw: Add support for polled operation via no IRQ specified in DT
> spi: dw: Add support for RX sample delay register
> spi: dw: Add support for client driver memory operations
> dt-bindings: spi: Add bindings for spi-dw-mchp
> spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
> dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
> spi: spi-dw-mchp: Add Sparx5 support
> arm64: dts: sparx5: Add SPI controller
> arm64: dts: sparx5: Add spi-nor support
> arm64: dts: sparx5: Add spi-nand devices
>
> .../bindings/spi/mscc,ocelot-spi.yaml | 89 ++++
> .../bindings/spi/snps,dw-apb-ssi.txt | 7 +-
> MAINTAINERS | 2 +
> arch/arm64/boot/dts/microchip/sparx5.dtsi | 37 ++
> .../boot/dts/microchip/sparx5_pcb125.dts | 16 +
> .../boot/dts/microchip/sparx5_pcb134.dts | 22 +
> .../dts/microchip/sparx5_pcb134_board.dtsi | 9 +
> .../boot/dts/microchip/sparx5_pcb135.dts | 23 +
> .../dts/microchip/sparx5_pcb135_board.dtsi | 9 +
> arch/mips/configs/generic/board-ocelot.config | 2 +-
> drivers/spi/Kconfig | 7 +
> drivers/spi/Makefile | 1 +
> drivers/spi/spi-dw-mchp.c | 399 ++++++++++++++++++
> drivers/spi/spi-dw-mmio.c | 93 ----
> drivers/spi/spi-dw.c | 31 +-
> drivers/spi/spi-dw.h | 4 +
> 16 files changed, 644 insertions(+), 107 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> create mode 100644 drivers/spi/spi-dw-mchp.c
>
> --
> 2.26.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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 v3 4/5] arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
From: Pavel Machek @ 2020-05-29 16:27 UTC (permalink / raw)
To: Ondrej Jirman
Cc: devicetree, Samuel Holland, David Airlie, Linus Walleij,
Bhushan Shah, Chen-Yu Tsai, Maxime Ripard, linux-kernel,
Martijn Braam, linux-sunxi, Rob Herring, Thierry Reding,
dri-devel, Daniel Vetter, Sam Ravnborg, Luca Weiss,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20200513212451.1919013-5-megous@megous.com>
[-- Attachment #1.1: Type: text/plain, Size: 1265 bytes --]
Hi!
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.
If it was possible to preserve lux values for individual settings in
the comment somewhere... that would be nice :-).
One day, it would be nice to have brightness settings in lux, so I
could easily set matching levels on multiple devices, for example...
Best regards,
Pavel
> +
> +&backlight {
> + power-supply = <®_ldo_io0>;
> + /*
> + * PWM backlight circuit on this PinePhone revision was changed since
> + * 1.0, and the lowest PWM duty cycle that doesn't lead to backlight
> + * being off is around 20%. Duty cycle for the lowest brightness level
> + * also varries quite a bit between individual boards, so the lowest
> + * value here was chosen as a safe default.
> + */
> + brightness-levels = <
> + 774 793 814 842
> + 882 935 1003 1088
> + 1192 1316 1462 1633
> + 1830 2054 2309 2596
> + 2916 3271 3664 4096>;
> + num-interpolated-steps = <50>;
> + default-brightness-level = <400>;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Pavel Machek @ 2020-05-29 16:28 UTC (permalink / raw)
To: Martin Kepplinger
Cc: robh, kernel, Anson.Huang, devicetree, shawnguo, s.hauer, angus,
linux-kernel, linux-imx, kernel, mchehab, festevam, agx,
linux-arm-kernel
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>
[-- Attachment #1.1: Type: text/plain, Size: 1342 bytes --]
Hi!
> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
>
> Add a devicetree description for the Librem 5 phone. The early batches
> that have been sold are supported as well as the mass-produced device
> available later this year, see https://puri.sm/products/librem-5/
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> + blue {
> + label = "phone:blue:front";
> + label = "phone:green:front";
> + label = "phone:red:front";
Droid 4 uses "status-led:{red,green,blue}". Could this use same
naming?
> + label = "lm3560:flash";
> + label = "lm3560:torch";
This is one LED, right? I'm pretty sure we don't want lm3560 in the
name... "main-camera:flash" would be better. Even better would be
something that's already in use.
> + label = "white:backlight_cluster";
Make this ":backlight", please. Again, we want something that's
already used.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH v5 0/6] Exynos: Simple QoS for exynos-bus using interconnect
From: Sylwester Nawrocki @ 2020-05-29 16:31 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, myungjoo.ham, s.nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <CGME20200529163213eucas1p1ac148f9238214ac84f3d0cc199c4398b@eucas1p1.samsung.com>
This patchset adds interconnect API support for the Exynos SoC "samsung,
exynos-bus" compatible devices, which already have their corresponding
exynos-bus driver in the devfreq subsystem. Complementing the devfreq driver
with an interconnect functionality allows to ensure the QoS requirements
of devices accessing the system memory (e.g. video processing devices)
are fulfilled and to avoid issues like the one discussed in thread [1].
This patch series depends on 3 patches from Artur for the interconnect API
[2], which introduce following changes:
- exporting of_icc_get_from_provider() to avoid hard coding every graph
edge in the DT or driver source,
- relaxing the requirement on #interconnect-cells, so there is no need
to provide dummy node IDs in the DT,
- adding new field in struct icc_provider to explicitly allow configuring
node pairs from two different providers.
This series adds implementation of interconnect provider per each "samsung,
exynos-bus" compatible DT node, with one interconnect node per provider.
The interconnect code which was previously added as a part of the devfreq
driver has been converted to a separate platform driver. In the devfreq
a corresponding virtual child platform device is registered. Integration
of devfreq and interconnect frameworks is achieved through the PM QoS API.
A sample interconnect consumer for exynos-mixer is added in patches 5/6,
6/6, it is currently added only for exynos4412 and allows to address the
mixer DMA underrun error issues [1].
The series has been tested on Odroid U3 board. It is based on icc-next
branch with devfreq-next branch merged and patches [2] applied.
--
Regards,
Sylwester
--
Changes since v3 [3] (v4 skipped to align with patchset [1]), detailed
changes are listed at each patch:
- conversion to a separate interconnect (platform) driver,
- an update of the DT binding documenting new optional properties:
#interconnect-cells, samsung,interconnect-parent in "samsung,exynos-bus"
nodes,
- new DT properties added to the SoC, rather than to the board specific
files.
Changes since v2 [5]:
- Use icc_std_aggregate().
- Implement a different modification of apply_constraints() in
drivers/interconnect/core.c (patch 03).
- Use 'exynos,interconnect-parent-node' in the DT instead of
'devfreq'/'parent', depending on the bus.
- Rebase on DT patches that deprecate the 'devfreq' DT property.
- Improve error handling, including freeing generated IDs on failure.
- Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent().
Changes since v1 [4]:
- Rebase on coupled regulators patches.
- Use dev_pm_qos_*() API instead of overriding frequency in
exynos_bus_target().
- Use IDR for node ID allocation.
- Reverse order of multiplication and division in
mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow.
References:
[1] https://patchwork.kernel.org/patch/10861757/ (original issue)
[2] https://www.spinics.net/lists/linux-samsung-soc/msg70014.html
[3] https://lore.kernel.org/linux-pm/20191220115653.6487-1-a.swigon@samsung.com
[4] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC)
[5] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC)
Artur Świgoń (1):
ARM: dts: exynos: Add interconnects to Exynos4412 mixer
Marek Szyprowski (1):
drm: exynos: mixer: Add interconnect support
Sylwester Nawrocki (4):
dt-bindings: exynos-bus: Add documentation for interconnect properties
interconnect: Add generic interconnect driver for Exynos SoCs
PM / devfreq: exynos-bus: Add registration of interconnect child
device
ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes
.../devicetree/bindings/devfreq/exynos-bus.txt | 15 +-
arch/arm/boot/dts/exynos4412.dtsi | 6 +
drivers/devfreq/exynos-bus.c | 17 ++
drivers/gpu/drm/exynos/exynos_mixer.c | 73 +++++++-
drivers/interconnect/Kconfig | 1 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/exynos/Kconfig | 6 +
drivers/interconnect/exynos/Makefile | 4 +
drivers/interconnect/exynos/exynos.c | 185 +++++++++++++++++++++
9 files changed, 301 insertions(+), 7 deletions(-)
create mode 100644 drivers/interconnect/exynos/Kconfig
create mode 100644 drivers/interconnect/exynos/Makefile
create mode 100644 drivers/interconnect/exynos/exynos.c
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH v5 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
From: Sylwester Nawrocki @ 2020-05-29 16:31 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, myungjoo.ham, s.nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200529163200.18031-1-s.nawrocki@samsung.com>
Add documentation for new optional properties in the exynos bus nodes:
samsung,interconnect-parent, #interconnect-cells.
These properties allow to specify the SoC interconnect structure which
then allows the interconnect consumer devices to request specific
bandwidth requirements.
Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes for v5:
- exynos,interconnect-parent-node renamed to samsung,interconnect-parent
---
Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index e71f752..e0d2daa 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -51,6 +51,11 @@ Optional properties only for parent bus device:
- exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
+Optional properties for interconnect functionality (QoS frequency constraints):
+- samsung,interconnect-parent: phandle to the parent interconnect node; for
+ passive devices should point to same node as the exynos,parent-bus property.
+- #interconnect-cells: should be 0
+
Detailed correlation between sub-blocks and power line according to Exynos SoC:
- In case of Exynos3250, there are two power line as following:
VDD_MIF |--- DMC
@@ -185,8 +190,9 @@ Example1:
----------------------------------------------------------
Example2 :
- The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
- is listed below:
+ The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi is
+ listed below. An interconnect path "bus_lcd0 -- bus_leftbus -- bus_dmc"
+ is defined for demonstration purposes.
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
@@ -376,12 +382,15 @@ Example2 :
&bus_dmc {
devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
vdd-supply = <&buck1_reg>; /* VDD_MIF */
+ #interconnect-cells = <0>;
status = "okay";
};
&bus_leftbus {
devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
vdd-supply = <&buck3_reg>;
+ samsung,interconnect-parent = <&bus_dmc>;
+ #interconnect-cells = <0>;
status = "okay";
};
@@ -392,6 +401,8 @@ Example2 :
&bus_lcd0 {
devfreq = <&bus_leftbus>;
+ samsung,interconnect-parent = <&bus_leftbus>;
+ #interconnect-cells = <0>;
status = "okay";
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH v5 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
From: Sylwester Nawrocki @ 2020-05-29 16:31 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, myungjoo.ham, s.nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200529163200.18031-1-s.nawrocki@samsung.com>
This patch adds a generic interconnect driver for Exynos SoCs in order
to provide interconnect functionality for each "samsung,exynos-bus"
compatible device.
The SoC topology is a graph (or more specifically, a tree) and its
edges are specified using the 'samsung,interconnect-parent' in the
DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
propagated to ensure that the parent is probed before its children.
Each bus is now an interconnect provider and an interconnect node as
well (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
registers itself as a node. Node IDs are not hardcoded but rather
assigned dynamically at runtime. This approach allows for using this
driver with various Exynos SoCs.
Frequencies requested via the interconnect API for a given node are
propagated to devfreq using dev_pm_qos_update_request(). Please note
that it is not an error when CONFIG_INTERCONNECT is 'n', in which
case all interconnect API functions are no-op.
Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Changes for v5:
- adjust to renamed exynos,interconnect-parent-node property,
- use automatically generated platform device id as the interconect
node id instead of a now unavailable devfreq->id field,
- add icc_ prefix to some variables to make the code more self-commenting,
- use icc_nodes_remove() instead of icc_node_del() + icc_node_destroy(),
- adjust to exynos,interconnect-parent-node property rename to
samsung,interconnect-parent,
- converted to a separate platform driver in drivers/interconnect.
---
drivers/interconnect/Kconfig | 1 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/exynos/Kconfig | 6 ++
drivers/interconnect/exynos/Makefile | 4 +
drivers/interconnect/exynos/exynos.c | 185 +++++++++++++++++++++++++++++++++++
5 files changed, 197 insertions(+)
create mode 100644 drivers/interconnect/exynos/Kconfig
create mode 100644 drivers/interconnect/exynos/Makefile
create mode 100644 drivers/interconnect/exynos/exynos.c
diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index 5b7204e..eca6eda 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -11,6 +11,7 @@ menuconfig INTERCONNECT
if INTERCONNECT
+source "drivers/interconnect/exynos/Kconfig"
source "drivers/interconnect/imx/Kconfig"
source "drivers/interconnect/qcom/Kconfig"
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 4825c28..2ba1de6 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -4,5 +4,6 @@ CFLAGS_core.o := -I$(src)
icc-core-objs := core.o
obj-$(CONFIG_INTERCONNECT) += icc-core.o
+obj-$(CONFIG_INTERCONNECT_EXYNOS) += exynos/
obj-$(CONFIG_INTERCONNECT_IMX) += imx/
obj-$(CONFIG_INTERCONNECT_QCOM) += qcom/
diff --git a/drivers/interconnect/exynos/Kconfig b/drivers/interconnect/exynos/Kconfig
new file mode 100644
index 0000000..e51e52e
--- /dev/null
+++ b/drivers/interconnect/exynos/Kconfig
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config INTERCONNECT_EXYNOS
+ tristate "Exynos generic interconnect driver"
+ depends on ARCH_EXYNOS || COMPILE_TEST
+ help
+ Generic interconnect driver for Exynos SoCs.
diff --git a/drivers/interconnect/exynos/Makefile b/drivers/interconnect/exynos/Makefile
new file mode 100644
index 0000000..e19d1df
--- /dev/null
+++ b/drivers/interconnect/exynos/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+exynos-interconnect-objs := exynos.o
+
+obj-$(CONFIG_INTERCONNECT_EXYNOS) += exynos-interconnect.o
diff --git a/drivers/interconnect/exynos/exynos.c b/drivers/interconnect/exynos/exynos.c
new file mode 100644
index 0000000..8278194
--- /dev/null
+++ b/drivers/interconnect/exynos/exynos.c
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Exynos generic interconnect provider driver
+ *
+ * Copyright (c) 2020 Samsung Electronics Co., Ltd.
+ *
+ * Authors: Artur Świgoń <a.swigon@samsung.com>
+ * Sylwester Nawrocki <s.nawrocki@samsung.com>
+ */
+#include <linux/device.h>
+#include <linux/interconnect-provider.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_qos.h>
+
+#define kbps_to_khz(x) ((x) / 8)
+
+struct exynos_icc_priv {
+ struct device *dev;
+
+ /* One interconnect node per provider */
+ struct icc_provider provider;
+ struct icc_node *node;
+
+ struct dev_pm_qos_request qos_req;
+};
+
+static struct icc_node *exynos_icc_get_parent(struct device_node *np)
+{
+ struct of_phandle_args args;
+ int num, ret;
+
+ num = of_count_phandle_with_args(np, "samsung,interconnect-parent",
+ "#interconnect-cells");
+ if (num != 1)
+ return NULL; /* parent nodes are optional */
+
+ ret = of_parse_phandle_with_args(np, "samsung,interconnect-parent",
+ "#interconnect-cells", 0, &args);
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ of_node_put(args.np);
+
+ return of_icc_get_from_provider(&args);
+}
+
+
+static int exynos_generic_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+ struct exynos_icc_priv *src_priv = src->data, *dst_priv = dst->data;
+ s32 src_freq = kbps_to_khz(max(src->avg_bw, src->peak_bw));
+ s32 dst_freq = kbps_to_khz(max(dst->avg_bw, dst->peak_bw));
+ int ret;
+
+ ret = dev_pm_qos_update_request(&src_priv->qos_req, src_freq);
+ if (ret < 0) {
+ dev_err(src_priv->dev, "failed to update PM QoS of %s\n",
+ src->name);
+ return ret;
+ }
+
+ ret = dev_pm_qos_update_request(&dst_priv->qos_req, dst_freq);
+ if (ret < 0) {
+ dev_err(dst_priv->dev, "failed to update PM QoS of %s\n",
+ dst->name);
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct icc_node *exynos_generic_icc_xlate(struct of_phandle_args *spec,
+ void *data)
+{
+ struct exynos_icc_priv *priv = data;
+
+ if (spec->np != priv->dev->parent->of_node)
+ return ERR_PTR(-EINVAL);
+
+ return priv->node;
+}
+
+static int exynos_generic_icc_remove(struct platform_device *pdev)
+{
+ struct exynos_icc_priv *priv = platform_get_drvdata(pdev);
+ struct icc_node *parent_node, *node = priv->node;
+
+ parent_node = exynos_icc_get_parent(priv->dev->parent->of_node);
+ if (parent_node && !IS_ERR(parent_node))
+ icc_link_destroy(node, parent_node);
+
+ icc_nodes_remove(&priv->provider);
+ icc_provider_del(&priv->provider);
+
+ return 0;
+}
+
+static int exynos_generic_icc_probe(struct platform_device *pdev)
+{
+ struct device *bus_dev = pdev->dev.parent;
+ struct exynos_icc_priv *priv;
+ struct icc_provider *provider;
+ struct icc_node *icc_node, *icc_parent_node;
+ int ret;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = &pdev->dev;
+ platform_set_drvdata(pdev, priv);
+
+ provider = &priv->provider;
+
+ provider->set = exynos_generic_icc_set;
+ provider->aggregate = icc_std_aggregate;
+ provider->xlate = exynos_generic_icc_xlate;
+ provider->dev = bus_dev;
+ provider->inter_set = true;
+ provider->data = priv;
+
+ ret = icc_provider_add(provider);
+ if (ret < 0)
+ return ret;
+
+ icc_node = icc_node_create(pdev->id);
+ if (IS_ERR(icc_node)) {
+ ret = PTR_ERR(icc_node);
+ goto err_prov_del;
+ }
+
+ priv->node = icc_node;
+ icc_node->name = bus_dev->of_node->name;
+ icc_node->data = priv;
+ icc_node_add(icc_node, provider);
+
+ icc_parent_node = exynos_icc_get_parent(bus_dev->of_node);
+ if (IS_ERR(icc_parent_node)) {
+ ret = PTR_ERR(icc_parent_node);
+ goto err_node_del;
+ }
+ if (icc_parent_node) {
+ ret = icc_link_create(icc_node, icc_parent_node->id);
+ if (ret < 0)
+ goto err_node_del;
+ }
+
+ /*
+ * Register a PM QoS request for the bus device for which also devfreq
+ * functionality is registered.
+ */
+ ret = dev_pm_qos_add_request(bus_dev, &priv->qos_req,
+ DEV_PM_QOS_MIN_FREQUENCY, 0);
+ if (ret < 0)
+ goto err_link_destroy;
+
+ return 0;
+
+err_link_destroy:
+ if (icc_parent_node)
+ icc_link_destroy(icc_node, icc_parent_node);
+err_node_del:
+ icc_nodes_remove(provider);
+err_prov_del:
+ icc_provider_del(provider);
+
+ return ret;
+}
+
+static struct platform_driver exynos_generic_icc_driver = {
+ .driver = {
+ .name = "exynos-generic-icc",
+ },
+ .probe = exynos_generic_icc_probe,
+ .remove = exynos_generic_icc_remove,
+};
+module_platform_driver(exynos_generic_icc_driver);
+
+MODULE_DESCRIPTION("Exynos generic interconnect driver");
+MODULE_AUTHOR("Artur Świgoń <a.swigon@samsung.com>");
+MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki@samsung.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:exynos-generic-icc");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH v5 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
From: Sylwester Nawrocki @ 2020-05-29 16:31 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, myungjoo.ham, s.nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200529163200.18031-1-s.nawrocki@samsung.com>
This patch adds registration of a child platform device for the exynos
interconnect driver. It is assumed that the interconnect provider will
only be needed when #interconnect-cells property is present in the bus
DT node, hence the child device will be created only when such a property
is present.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Changes for v5:
- new patch.
---
drivers/devfreq/exynos-bus.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 8fa8eb5..856e37d 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -24,6 +24,7 @@
struct exynos_bus {
struct device *dev;
+ struct platform_device *icc_pdev;
struct devfreq *devfreq;
struct devfreq_event_dev **edev;
@@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
if (ret < 0)
dev_warn(dev, "failed to disable the devfreq-event devices\n");
+ platform_device_unregister(bus->icc_pdev);
+
dev_pm_opp_of_remove_table(dev);
clk_disable_unprepare(bus->clk);
if (bus->opp_table) {
@@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
{
struct exynos_bus *bus = dev_get_drvdata(dev);
+ platform_device_unregister(bus->icc_pdev);
+
dev_pm_opp_of_remove_table(dev);
clk_disable_unprepare(bus->clk);
}
@@ -431,6 +436,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
if (ret < 0)
goto err;
+ /* Create child platform device for the interconnect provider */
+ if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
+ bus->icc_pdev = platform_device_register_data(
+ dev, "exynos-generic-icc",
+ PLATFORM_DEVID_AUTO, NULL, 0);
+
+ if (IS_ERR(bus->icc_pdev)) {
+ ret = PTR_ERR(bus->icc_pdev);
+ goto err;
+ }
+ }
+
max_state = bus->devfreq->profile->max_state;
min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC PATCH v5 4/6] ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes
From: Sylwester Nawrocki @ 2020-05-29 16:31 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, myungjoo.ham, s.nawrocki,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200529163200.18031-1-s.nawrocki@samsung.com>
This patch adds the following properties for Exynos4412 interconnect
bus nodes:
- samsung,interconnect-parent: to declare connections between
nodes in order to guarantee PM QoS requirements between nodes;
- #interconnect-cells: required by the interconnect framework.
Note that #interconnect-cells is always zero and node IDs are not
hardcoded anywhere.
Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
Changes for v5:
- adjust to renamed exynos,interconnect-parent-node property,
- add properties in common exynos4412.dtsi file rather than
in Odroid specific odroid4412-odroid-common.dtsi.
---
arch/arm/boot/dts/exynos4412.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 4886894..a7496d3 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -381,6 +381,7 @@
clocks = <&clock CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
+ #interconnect-cells = <0>;
status = "disabled";
};
@@ -450,6 +451,8 @@
clocks = <&clock CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
+ samsung,interconnect-parent = <&bus_dmc>;
+ #interconnect-cells = <0>;
status = "disabled";
};
@@ -466,6 +469,8 @@
clocks = <&clock CLK_ACLK160>;
clock-names = "bus";
operating-points-v2 = <&bus_display_opp_table>;
+ samsung,interconnect-parent = <&bus_leftbus>;
+ #interconnect-cells = <0>;
status = "disabled";
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox