All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] KVM: arm64: Fix DEMUX register access
@ 2020-11-26 13:46 ` Andrew Jones
  0 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 13:46 UTC (permalink / raw)
  To: kvm, kvmarm; +Cc: maz, pbonzini

The first patch is a fix, but not one likely to ever truly be needed,
as it's unlikely to find seven levels of cache. The bug was found
while code reading. Writing the second patch was actually why I was
reading the code. The issue being fixed for the get-reg-list test was
found when running it on a different machine than what was used to
develop it.

Thanks,
drew

Andrew Jones (2):
  KVM: arm64: CSSELR_EL1 max is 13
  KVM: selftests: Filter out DEMUX registers

 arch/arm64/kvm/sys_regs.c                     |  2 +-
 .../selftests/kvm/aarch64/get-reg-list.c      | 39 ++++++++++++++-----
 2 files changed, 31 insertions(+), 10 deletions(-)

-- 
2.26.2


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH 0/2] KVM: arm64: Fix DEMUX register access
@ 2020-11-26 13:46 ` Andrew Jones
  0 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 13:46 UTC (permalink / raw)
  To: kvm, kvmarm; +Cc: maz, pbonzini

The first patch is a fix, but not one likely to ever truly be needed,
as it's unlikely to find seven levels of cache. The bug was found
while code reading. Writing the second patch was actually why I was
reading the code. The issue being fixed for the get-reg-list test was
found when running it on a different machine than what was used to
develop it.

Thanks,
drew

Andrew Jones (2):
  KVM: arm64: CSSELR_EL1 max is 13
  KVM: selftests: Filter out DEMUX registers

 arch/arm64/kvm/sys_regs.c                     |  2 +-
 .../selftests/kvm/aarch64/get-reg-list.c      | 39 ++++++++++++++-----
 2 files changed, 31 insertions(+), 10 deletions(-)

-- 
2.26.2

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
  2020-11-26 13:46 ` Andrew Jones
@ 2020-11-26 13:46   ` Andrew Jones
  -1 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 13:46 UTC (permalink / raw)
  To: kvm, kvmarm; +Cc: maz, pbonzini

Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
can have a maximum value of 0b1101 (13), which corresponds to an
instruction cache at level 7. With CSSELR_MAX set to 12 we can
only select up to cache level 6. Change it to 14.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c1fac9836af1..ef453f7827fa 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg)
 static u32 cache_levels;
 
 /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
-#define CSSELR_MAX 12
+#define CSSELR_MAX 14
 
 /* Which cache CCSIDR represents depends on CSSELR value. */
 static u32 get_ccsidr(u32 csselr)
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
@ 2020-11-26 13:46   ` Andrew Jones
  0 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 13:46 UTC (permalink / raw)
  To: kvm, kvmarm; +Cc: maz, pbonzini

Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
can have a maximum value of 0b1101 (13), which corresponds to an
instruction cache at level 7. With CSSELR_MAX set to 12 we can
only select up to cache level 6. Change it to 14.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c1fac9836af1..ef453f7827fa 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg)
 static u32 cache_levels;
 
 /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
-#define CSSELR_MAX 12
+#define CSSELR_MAX 14
 
 /* Which cache CCSIDR represents depends on CSSELR value. */
 static u32 get_ccsidr(u32 csselr)
-- 
2.26.2

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH 2/2] KVM: selftests: Filter out DEMUX registers
  2020-11-26 13:46 ` Andrew Jones
@ 2020-11-26 13:46   ` Andrew Jones
  -1 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 13:46 UTC (permalink / raw)
  To: kvm, kvmarm; +Cc: maz, pbonzini

DEMUX register presence depends on the host's hardware (the
CLIDR_EL1 register to be precise). This means there's no set
of them that we can bless and that it's possible to encounter
new ones when running on different hardware (which would
generate "Consider adding them ..." messages, but we'll never
want to add them.)

Remove the ones we have in the blessed list and filter them
out of the new list, but also provide a new command line switch
to list them if one so desires.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 .../selftests/kvm/aarch64/get-reg-list.c      | 39 ++++++++++++++-----
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index 33218a395d9f..486932164cf2 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -42,12 +42,16 @@
 #define for_each_reg(i)								\
 	for ((i) = 0; (i) < reg_list->n; ++(i))
 
+#define for_each_reg_filtered(i)						\
+	for_each_reg(i)								\
+		if (!filter_reg(reg_list->reg[i]))
+
 #define for_each_missing_reg(i)							\
 	for ((i) = 0; (i) < blessed_n; ++(i))					\
 		if (!find_reg(reg_list->reg, reg_list->n, blessed_reg[i]))
 
 #define for_each_new_reg(i)							\
-	for ((i) = 0; (i) < reg_list->n; ++(i))					\
+	for_each_reg_filtered(i)						\
 		if (!find_reg(blessed_reg, blessed_n, reg_list->reg[i]))
 
 
@@ -57,6 +61,18 @@ static __u64 base_regs[], vregs[], sve_regs[], rejects_set[];
 static __u64 base_regs_n, vregs_n, sve_regs_n, rejects_set_n;
 static __u64 *blessed_reg, blessed_n;
 
+static bool filter_reg(__u64 reg)
+{
+	/*
+	 * DEMUX register presence depends on the host's CLIDR_EL1.
+	 * This means there's no set of them that we can bless.
+	 */
+	if ((reg & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_DEMUX)
+		return true;
+
+	return false;
+}
+
 static bool find_reg(__u64 regs[], __u64 nr_regs, __u64 reg)
 {
 	int i;
@@ -325,7 +341,7 @@ int main(int ac, char **av)
 	struct kvm_vcpu_init init = { .target = -1, };
 	int new_regs = 0, missing_regs = 0, i;
 	int failed_get = 0, failed_set = 0, failed_reject = 0;
-	bool print_list = false, fixup_core_regs = false;
+	bool print_list = false, print_filtered = false, fixup_core_regs = false;
 	struct kvm_vm *vm;
 	__u64 *vec_regs;
 
@@ -336,8 +352,10 @@ int main(int ac, char **av)
 			fixup_core_regs = true;
 		else if (strcmp(av[i], "--list") == 0)
 			print_list = true;
+		else if (strcmp(av[i], "--list-filtered") == 0)
+			print_filtered = true;
 		else
-			fprintf(stderr, "Ignoring unknown option: %s\n", av[i]);
+			TEST_FAIL("Unknown option: %s\n", av[i]);
 	}
 
 	vm = vm_create(VM_MODE_DEFAULT, DEFAULT_GUEST_PHY_PAGES, O_RDWR);
@@ -350,10 +368,14 @@ int main(int ac, char **av)
 	if (fixup_core_regs)
 		core_reg_fixup();
 
-	if (print_list) {
+	if (print_list || print_filtered) {
 		putchar('\n');
-		for_each_reg(i)
-			print_reg(reg_list->reg[i]);
+		for_each_reg(i) {
+			__u64 id = reg_list->reg[i];
+			if ((print_list && !filter_reg(id)) ||
+			    (print_filtered && filter_reg(id)))
+				print_reg(id);
+		}
 		putchar('\n');
 		return 0;
 	}
@@ -458,6 +480,8 @@ int main(int ac, char **av)
 /*
  * The current blessed list was primed with the output of kernel version
  * v4.15 with --core-reg-fixup and then later updated with new registers.
+ *
+ * The blessed list is up to date with kernel version v5.10-rc5
  */
 static __u64 base_regs[] = {
 	KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(regs.regs[0]),
@@ -736,9 +760,6 @@ static __u64 base_regs[] = {
 	ARM64_SYS_REG(3, 4, 3, 0, 0),	/* DACR32_EL2 */
 	ARM64_SYS_REG(3, 4, 5, 0, 1),	/* IFSR32_EL2 */
 	ARM64_SYS_REG(3, 4, 5, 3, 0),	/* FPEXC32_EL2 */
-	KVM_REG_ARM64 | KVM_REG_SIZE_U32 | KVM_REG_ARM_DEMUX | KVM_REG_ARM_DEMUX_ID_CCSIDR | 0,
-	KVM_REG_ARM64 | KVM_REG_SIZE_U32 | KVM_REG_ARM_DEMUX | KVM_REG_ARM_DEMUX_ID_CCSIDR | 1,
-	KVM_REG_ARM64 | KVM_REG_SIZE_U32 | KVM_REG_ARM_DEMUX | KVM_REG_ARM_DEMUX_ID_CCSIDR | 2,
 };
 static __u64 base_regs_n = ARRAY_SIZE(base_regs);
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH 2/2] KVM: selftests: Filter out DEMUX registers
@ 2020-11-26 13:46   ` Andrew Jones
  0 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 13:46 UTC (permalink / raw)
  To: kvm, kvmarm; +Cc: maz, pbonzini

DEMUX register presence depends on the host's hardware (the
CLIDR_EL1 register to be precise). This means there's no set
of them that we can bless and that it's possible to encounter
new ones when running on different hardware (which would
generate "Consider adding them ..." messages, but we'll never
want to add them.)

Remove the ones we have in the blessed list and filter them
out of the new list, but also provide a new command line switch
to list them if one so desires.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 .../selftests/kvm/aarch64/get-reg-list.c      | 39 ++++++++++++++-----
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index 33218a395d9f..486932164cf2 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -42,12 +42,16 @@
 #define for_each_reg(i)								\
 	for ((i) = 0; (i) < reg_list->n; ++(i))
 
+#define for_each_reg_filtered(i)						\
+	for_each_reg(i)								\
+		if (!filter_reg(reg_list->reg[i]))
+
 #define for_each_missing_reg(i)							\
 	for ((i) = 0; (i) < blessed_n; ++(i))					\
 		if (!find_reg(reg_list->reg, reg_list->n, blessed_reg[i]))
 
 #define for_each_new_reg(i)							\
-	for ((i) = 0; (i) < reg_list->n; ++(i))					\
+	for_each_reg_filtered(i)						\
 		if (!find_reg(blessed_reg, blessed_n, reg_list->reg[i]))
 
 
@@ -57,6 +61,18 @@ static __u64 base_regs[], vregs[], sve_regs[], rejects_set[];
 static __u64 base_regs_n, vregs_n, sve_regs_n, rejects_set_n;
 static __u64 *blessed_reg, blessed_n;
 
+static bool filter_reg(__u64 reg)
+{
+	/*
+	 * DEMUX register presence depends on the host's CLIDR_EL1.
+	 * This means there's no set of them that we can bless.
+	 */
+	if ((reg & KVM_REG_ARM_COPROC_MASK) == KVM_REG_ARM_DEMUX)
+		return true;
+
+	return false;
+}
+
 static bool find_reg(__u64 regs[], __u64 nr_regs, __u64 reg)
 {
 	int i;
@@ -325,7 +341,7 @@ int main(int ac, char **av)
 	struct kvm_vcpu_init init = { .target = -1, };
 	int new_regs = 0, missing_regs = 0, i;
 	int failed_get = 0, failed_set = 0, failed_reject = 0;
-	bool print_list = false, fixup_core_regs = false;
+	bool print_list = false, print_filtered = false, fixup_core_regs = false;
 	struct kvm_vm *vm;
 	__u64 *vec_regs;
 
@@ -336,8 +352,10 @@ int main(int ac, char **av)
 			fixup_core_regs = true;
 		else if (strcmp(av[i], "--list") == 0)
 			print_list = true;
+		else if (strcmp(av[i], "--list-filtered") == 0)
+			print_filtered = true;
 		else
-			fprintf(stderr, "Ignoring unknown option: %s\n", av[i]);
+			TEST_FAIL("Unknown option: %s\n", av[i]);
 	}
 
 	vm = vm_create(VM_MODE_DEFAULT, DEFAULT_GUEST_PHY_PAGES, O_RDWR);
@@ -350,10 +368,14 @@ int main(int ac, char **av)
 	if (fixup_core_regs)
 		core_reg_fixup();
 
-	if (print_list) {
+	if (print_list || print_filtered) {
 		putchar('\n');
-		for_each_reg(i)
-			print_reg(reg_list->reg[i]);
+		for_each_reg(i) {
+			__u64 id = reg_list->reg[i];
+			if ((print_list && !filter_reg(id)) ||
+			    (print_filtered && filter_reg(id)))
+				print_reg(id);
+		}
 		putchar('\n');
 		return 0;
 	}
@@ -458,6 +480,8 @@ int main(int ac, char **av)
 /*
  * The current blessed list was primed with the output of kernel version
  * v4.15 with --core-reg-fixup and then later updated with new registers.
+ *
+ * The blessed list is up to date with kernel version v5.10-rc5
  */
 static __u64 base_regs[] = {
 	KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE | KVM_REG_ARM_CORE_REG(regs.regs[0]),
@@ -736,9 +760,6 @@ static __u64 base_regs[] = {
 	ARM64_SYS_REG(3, 4, 3, 0, 0),	/* DACR32_EL2 */
 	ARM64_SYS_REG(3, 4, 5, 0, 1),	/* IFSR32_EL2 */
 	ARM64_SYS_REG(3, 4, 5, 3, 0),	/* FPEXC32_EL2 */
-	KVM_REG_ARM64 | KVM_REG_SIZE_U32 | KVM_REG_ARM_DEMUX | KVM_REG_ARM_DEMUX_ID_CCSIDR | 0,
-	KVM_REG_ARM64 | KVM_REG_SIZE_U32 | KVM_REG_ARM_DEMUX | KVM_REG_ARM_DEMUX_ID_CCSIDR | 1,
-	KVM_REG_ARM64 | KVM_REG_SIZE_U32 | KVM_REG_ARM_DEMUX | KVM_REG_ARM_DEMUX_ID_CCSIDR | 2,
 };
 static __u64 base_regs_n = ARRAY_SIZE(base_regs);
 
-- 
2.26.2

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
  2020-11-26 13:46   ` Andrew Jones
@ 2020-11-26 14:13     ` Marc Zyngier
  -1 siblings, 0 replies; 16+ messages in thread
From: Marc Zyngier @ 2020-11-26 14:13 UTC (permalink / raw)
  To: Andrew Jones; +Cc: kvm, kvmarm, pbonzini

On 2020-11-26 13:46, Andrew Jones wrote:
> Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
> can have a maximum value of 0b1101 (13), which corresponds to an
> instruction cache at level 7. With CSSELR_MAX set to 12 we can
> only select up to cache level 6. Change it to 14.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/arm64/kvm/sys_regs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index c1fac9836af1..ef453f7827fa 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64
> val, int reg)
>  static u32 cache_levels;
> 
>  /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
> -#define CSSELR_MAX 12
> +#define CSSELR_MAX 14
> 
>  /* Which cache CCSIDR represents depends on CSSELR value. */
>  static u32 get_ccsidr(u32 csselr)

Huh, nice catch. Do we need a CC: stable tag for this?

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
@ 2020-11-26 14:13     ` Marc Zyngier
  0 siblings, 0 replies; 16+ messages in thread
From: Marc Zyngier @ 2020-11-26 14:13 UTC (permalink / raw)
  To: Andrew Jones; +Cc: pbonzini, kvmarm, kvm

On 2020-11-26 13:46, Andrew Jones wrote:
> Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
> can have a maximum value of 0b1101 (13), which corresponds to an
> instruction cache at level 7. With CSSELR_MAX set to 12 we can
> only select up to cache level 6. Change it to 14.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/arm64/kvm/sys_regs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index c1fac9836af1..ef453f7827fa 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64
> val, int reg)
>  static u32 cache_levels;
> 
>  /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
> -#define CSSELR_MAX 12
> +#define CSSELR_MAX 14
> 
>  /* Which cache CCSIDR represents depends on CSSELR value. */
>  static u32 get_ccsidr(u32 csselr)

Huh, nice catch. Do we need a CC: stable tag for this?

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
  2020-11-26 14:13     ` Marc Zyngier
@ 2020-11-26 14:32       ` Andrew Jones
  -1 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 14:32 UTC (permalink / raw)
  To: Marc Zyngier; +Cc: kvm, kvmarm, pbonzini

On Thu, Nov 26, 2020 at 02:13:44PM +0000, Marc Zyngier wrote:
> On 2020-11-26 13:46, Andrew Jones wrote:
> > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
> > can have a maximum value of 0b1101 (13), which corresponds to an
> > instruction cache at level 7. With CSSELR_MAX set to 12 we can
> > only select up to cache level 6. Change it to 14.
> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  arch/arm64/kvm/sys_regs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index c1fac9836af1..ef453f7827fa 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64
> > val, int reg)
> >  static u32 cache_levels;
> > 
> >  /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
> > -#define CSSELR_MAX 12
> > +#define CSSELR_MAX 14
> > 
> >  /* Which cache CCSIDR represents depends on CSSELR value. */
> >  static u32 get_ccsidr(u32 csselr)
> 
> Huh, nice catch. Do we need a CC: stable tag for this?
>

Hi Marc,

I wasn't thinking so, because I'm not expecting there to actually
be hardware with seven cache levels in the wild any time soon. You
have more knowledge about what's out there and coming, though, so
feel free CC stable if needed.

Thanks,
drew


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
@ 2020-11-26 14:32       ` Andrew Jones
  0 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 14:32 UTC (permalink / raw)
  To: Marc Zyngier; +Cc: pbonzini, kvmarm, kvm

On Thu, Nov 26, 2020 at 02:13:44PM +0000, Marc Zyngier wrote:
> On 2020-11-26 13:46, Andrew Jones wrote:
> > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
> > can have a maximum value of 0b1101 (13), which corresponds to an
> > instruction cache at level 7. With CSSELR_MAX set to 12 we can
> > only select up to cache level 6. Change it to 14.
> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  arch/arm64/kvm/sys_regs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index c1fac9836af1..ef453f7827fa 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64
> > val, int reg)
> >  static u32 cache_levels;
> > 
> >  /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
> > -#define CSSELR_MAX 12
> > +#define CSSELR_MAX 14
> > 
> >  /* Which cache CCSIDR represents depends on CSSELR value. */
> >  static u32 get_ccsidr(u32 csselr)
> 
> Huh, nice catch. Do we need a CC: stable tag for this?
>

Hi Marc,

I wasn't thinking so, because I'm not expecting there to actually
be hardware with seven cache levels in the wild any time soon. You
have more knowledge about what's out there and coming, though, so
feel free CC stable if needed.

Thanks,
drew

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
  2020-11-26 14:32       ` Andrew Jones
@ 2020-11-26 14:34         ` Marc Zyngier
  -1 siblings, 0 replies; 16+ messages in thread
From: Marc Zyngier @ 2020-11-26 14:34 UTC (permalink / raw)
  To: Andrew Jones; +Cc: kvm, kvmarm, pbonzini

On 2020-11-26 14:32, Andrew Jones wrote:
> On Thu, Nov 26, 2020 at 02:13:44PM +0000, Marc Zyngier wrote:
>> On 2020-11-26 13:46, Andrew Jones wrote:
>> > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
>> > can have a maximum value of 0b1101 (13), which corresponds to an
>> > instruction cache at level 7. With CSSELR_MAX set to 12 we can
>> > only select up to cache level 6. Change it to 14.
>> >
>> > Signed-off-by: Andrew Jones <drjones@redhat.com>
>> > ---
>> >  arch/arm64/kvm/sys_regs.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index c1fac9836af1..ef453f7827fa 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64
>> > val, int reg)
>> >  static u32 cache_levels;
>> >
>> >  /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
>> > -#define CSSELR_MAX 12
>> > +#define CSSELR_MAX 14
>> >
>> >  /* Which cache CCSIDR represents depends on CSSELR value. */
>> >  static u32 get_ccsidr(u32 csselr)
>> 
>> Huh, nice catch. Do we need a CC: stable tag for this?
>> 
> 
> Hi Marc,
> 
> I wasn't thinking so, because I'm not expecting there to actually
> be hardware with seven cache levels in the wild any time soon. You
> have more knowledge about what's out there and coming, though, so
> feel free CC stable if needed.

That's actually what I was wondering, whether you had seen that in the
wild already. Since you haven't (and I'm not aware of such a 
monstrosity),
I'll queue it for 5.11.

Do you want me to take the selftest stuff at the same time?

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
@ 2020-11-26 14:34         ` Marc Zyngier
  0 siblings, 0 replies; 16+ messages in thread
From: Marc Zyngier @ 2020-11-26 14:34 UTC (permalink / raw)
  To: Andrew Jones; +Cc: pbonzini, kvmarm, kvm

On 2020-11-26 14:32, Andrew Jones wrote:
> On Thu, Nov 26, 2020 at 02:13:44PM +0000, Marc Zyngier wrote:
>> On 2020-11-26 13:46, Andrew Jones wrote:
>> > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
>> > can have a maximum value of 0b1101 (13), which corresponds to an
>> > instruction cache at level 7. With CSSELR_MAX set to 12 we can
>> > only select up to cache level 6. Change it to 14.
>> >
>> > Signed-off-by: Andrew Jones <drjones@redhat.com>
>> > ---
>> >  arch/arm64/kvm/sys_regs.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index c1fac9836af1..ef453f7827fa 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64
>> > val, int reg)
>> >  static u32 cache_levels;
>> >
>> >  /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
>> > -#define CSSELR_MAX 12
>> > +#define CSSELR_MAX 14
>> >
>> >  /* Which cache CCSIDR represents depends on CSSELR value. */
>> >  static u32 get_ccsidr(u32 csselr)
>> 
>> Huh, nice catch. Do we need a CC: stable tag for this?
>> 
> 
> Hi Marc,
> 
> I wasn't thinking so, because I'm not expecting there to actually
> be hardware with seven cache levels in the wild any time soon. You
> have more knowledge about what's out there and coming, though, so
> feel free CC stable if needed.

That's actually what I was wondering, whether you had seen that in the
wild already. Since you haven't (and I'm not aware of such a 
monstrosity),
I'll queue it for 5.11.

Do you want me to take the selftest stuff at the same time?

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
  2020-11-26 14:34         ` Marc Zyngier
@ 2020-11-26 14:36           ` Andrew Jones
  -1 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 14:36 UTC (permalink / raw)
  To: Marc Zyngier; +Cc: kvm, kvmarm, pbonzini

On Thu, Nov 26, 2020 at 02:34:05PM +0000, Marc Zyngier wrote:
> On 2020-11-26 14:32, Andrew Jones wrote:
> > On Thu, Nov 26, 2020 at 02:13:44PM +0000, Marc Zyngier wrote:
> > > On 2020-11-26 13:46, Andrew Jones wrote:
> > > > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
> > > > can have a maximum value of 0b1101 (13), which corresponds to an
> > > > instruction cache at level 7. With CSSELR_MAX set to 12 we can
> > > > only select up to cache level 6. Change it to 14.
> > > >
> > > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > > ---
> > > >  arch/arm64/kvm/sys_regs.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > > > index c1fac9836af1..ef453f7827fa 100644
> > > > --- a/arch/arm64/kvm/sys_regs.c
> > > > +++ b/arch/arm64/kvm/sys_regs.c
> > > > @@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64
> > > > val, int reg)
> > > >  static u32 cache_levels;
> > > >
> > > >  /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
> > > > -#define CSSELR_MAX 12
> > > > +#define CSSELR_MAX 14
> > > >
> > > >  /* Which cache CCSIDR represents depends on CSSELR value. */
> > > >  static u32 get_ccsidr(u32 csselr)
> > > 
> > > Huh, nice catch. Do we need a CC: stable tag for this?
> > > 
> > 
> > Hi Marc,
> > 
> > I wasn't thinking so, because I'm not expecting there to actually
> > be hardware with seven cache levels in the wild any time soon. You
> > have more knowledge about what's out there and coming, though, so
> > feel free CC stable if needed.
> 
> That's actually what I was wondering, whether you had seen that in the
> wild already. Since you haven't (and I'm not aware of such a monstrosity),
> I'll queue it for 5.11.
> 
> Do you want me to take the selftest stuff at the same time?
>

Yes, please :)

Thanks,
drew 


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13
@ 2020-11-26 14:36           ` Andrew Jones
  0 siblings, 0 replies; 16+ messages in thread
From: Andrew Jones @ 2020-11-26 14:36 UTC (permalink / raw)
  To: Marc Zyngier; +Cc: pbonzini, kvmarm, kvm

On Thu, Nov 26, 2020 at 02:34:05PM +0000, Marc Zyngier wrote:
> On 2020-11-26 14:32, Andrew Jones wrote:
> > On Thu, Nov 26, 2020 at 02:13:44PM +0000, Marc Zyngier wrote:
> > > On 2020-11-26 13:46, Andrew Jones wrote:
> > > > Not counting TnD, which KVM doesn't currently consider, CSSELR_EL1
> > > > can have a maximum value of 0b1101 (13), which corresponds to an
> > > > instruction cache at level 7. With CSSELR_MAX set to 12 we can
> > > > only select up to cache level 6. Change it to 14.
> > > >
> > > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > > ---
> > > >  arch/arm64/kvm/sys_regs.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > > > index c1fac9836af1..ef453f7827fa 100644
> > > > --- a/arch/arm64/kvm/sys_regs.c
> > > > +++ b/arch/arm64/kvm/sys_regs.c
> > > > @@ -169,7 +169,7 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64
> > > > val, int reg)
> > > >  static u32 cache_levels;
> > > >
> > > >  /* CSSELR values; used to index KVM_REG_ARM_DEMUX_ID_CCSIDR */
> > > > -#define CSSELR_MAX 12
> > > > +#define CSSELR_MAX 14
> > > >
> > > >  /* Which cache CCSIDR represents depends on CSSELR value. */
> > > >  static u32 get_ccsidr(u32 csselr)
> > > 
> > > Huh, nice catch. Do we need a CC: stable tag for this?
> > > 
> > 
> > Hi Marc,
> > 
> > I wasn't thinking so, because I'm not expecting there to actually
> > be hardware with seven cache levels in the wild any time soon. You
> > have more knowledge about what's out there and coming, though, so
> > feel free CC stable if needed.
> 
> That's actually what I was wondering, whether you had seen that in the
> wild already. Since you haven't (and I'm not aware of such a monstrosity),
> I'll queue it for 5.11.
> 
> Do you want me to take the selftest stuff at the same time?
>

Yes, please :)

Thanks,
drew 

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 0/2] KVM: arm64: Fix DEMUX register access
  2020-11-26 13:46 ` Andrew Jones
@ 2020-11-27 19:47   ` Marc Zyngier
  -1 siblings, 0 replies; 16+ messages in thread
From: Marc Zyngier @ 2020-11-27 19:47 UTC (permalink / raw)
  To: Andrew Jones, kvmarm, kvm; +Cc: pbonzini

On Thu, 26 Nov 2020 14:46:39 +0100, Andrew Jones wrote:
> The first patch is a fix, but not one likely to ever truly be needed,
> as it's unlikely to find seven levels of cache. The bug was found
> while code reading. Writing the second patch was actually why I was
> reading the code. The issue being fixed for the get-reg-list test was
> found when running it on a different machine than what was used to
> develop it.
> 
> [...]

Applied to kvm-arm64/cache-demux, thanks!

[1/2] KVM: arm64: CSSELR_EL1 max is 13
      commit: c73a44161776f6e60d933717f3b34084b0a0eba0
[2/2] KVM: arm64: selftests: Filter out DEMUX registers
      commit: c6232bd40b2eda3819d108e6e3f621ec604e15d8

Cheers,

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



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH 0/2] KVM: arm64: Fix DEMUX register access
@ 2020-11-27 19:47   ` Marc Zyngier
  0 siblings, 0 replies; 16+ messages in thread
From: Marc Zyngier @ 2020-11-27 19:47 UTC (permalink / raw)
  To: Andrew Jones, kvmarm, kvm; +Cc: pbonzini

On Thu, 26 Nov 2020 14:46:39 +0100, Andrew Jones wrote:
> The first patch is a fix, but not one likely to ever truly be needed,
> as it's unlikely to find seven levels of cache. The bug was found
> while code reading. Writing the second patch was actually why I was
> reading the code. The issue being fixed for the get-reg-list test was
> found when running it on a different machine than what was used to
> develop it.
> 
> [...]

Applied to kvm-arm64/cache-demux, thanks!

[1/2] KVM: arm64: CSSELR_EL1 max is 13
      commit: c73a44161776f6e60d933717f3b34084b0a0eba0
[2/2] KVM: arm64: selftests: Filter out DEMUX registers
      commit: c6232bd40b2eda3819d108e6e3f621ec604e15d8

Cheers,

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


_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2020-11-28 22:19 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-26 13:46 [PATCH 0/2] KVM: arm64: Fix DEMUX register access Andrew Jones
2020-11-26 13:46 ` Andrew Jones
2020-11-26 13:46 ` [PATCH 1/2] KVM: arm64: CSSELR_EL1 max is 13 Andrew Jones
2020-11-26 13:46   ` Andrew Jones
2020-11-26 14:13   ` Marc Zyngier
2020-11-26 14:13     ` Marc Zyngier
2020-11-26 14:32     ` Andrew Jones
2020-11-26 14:32       ` Andrew Jones
2020-11-26 14:34       ` Marc Zyngier
2020-11-26 14:34         ` Marc Zyngier
2020-11-26 14:36         ` Andrew Jones
2020-11-26 14:36           ` Andrew Jones
2020-11-26 13:46 ` [PATCH 2/2] KVM: selftests: Filter out DEMUX registers Andrew Jones
2020-11-26 13:46   ` Andrew Jones
2020-11-27 19:47 ` [PATCH 0/2] KVM: arm64: Fix DEMUX register access Marc Zyngier
2020-11-27 19:47   ` Marc Zyngier

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.