[PATCH 0/2] KVM: arm64: PMU: Preserve vPMC registers properly on migration

[PATCH 0/2] KVM: arm64: PMU: Preserve vPMC registers properly on migration

[Reiji Watanabe]

The series fixes two problems in preserving vPMU counter (vPMC)
registers (PMCCNTR_EL0/PMEVCNTR<n>_EL0) during migration.

One of the problems is that KVM may not return the current values
of the vPMC registers for KVM_GET_ONE_REG.

The other one might cause KVM to reset the vPMC registers on the
first KVM_RUN on the destination. This is because userspace might
save PMCR_EL0 with PMCR_EL0.{C,P} bits set on the source, and
restore it on the destination.

See patch-1 and patch-2 for details on these issues respectively.

The series is based on v6.2.

Reiji Watanabe (2):
  KVM: arm64: PMU: Fix GET_ONE_REG for vPMC regs to return the current
    value
  KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPU

 arch/arm64/kvm/pmu-emul.c |  4 +++-
 arch/arm64/kvm/sys_regs.c | 21 +++++++++++++++++++--
 2 files changed, 22 insertions(+), 3 deletions(-)


base-commit: c9c3395d5e3dcc6daee66c6908354d47bf98cb0c
-- 
2.39.2.722.g9855ee24e9-goog

[PATCH 1/2] KVM: arm64: PMU: Fix GET_ONE_REG for vPMC regs to return the current value

[Reiji Watanabe]

Have KVM_GET_ONE_REG for vPMU counter (vPMC) registers (PMCCNTR_EL0
and PMEVCNTR<n>_EL0) return the sum of the register value in the sysreg
file and the current perf event counter value.

Values of vPMC registers are saved in sysreg files on certain occasions.
These saved values don't represent the current values of the vPMC
registers if the perf events for the vPMCs count events after the save.
The current values of those registers are the sum of the sysreg file
value and the current perf event counter value.  But, when userspace
reads those registers (using KVM_GET_ONE_REG), KVM returns the sysreg
file value to userspace (not the sum value).

Fix this to return the sum value for KVM_GET_ONE_REG.

Signed-off-by: Reiji Watanabe <reijiw@google.com>
---
 arch/arm64/kvm/sys_regs.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c6cbfe6b854b..c48c053d6146 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -765,6 +765,22 @@ static bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
 	return true;
 }
 
+static int get_pmu_evcntr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
+			  u64 *val)
+{
+	u64 idx;
+
+	if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 0)
+		/* PMCCNTR_EL0 */
+		idx = ARMV8_PMU_CYCLE_IDX;
+	else
+		/* PMEVCNTRn_EL0 */
+		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+
+	*val = kvm_pmu_get_counter_value(vcpu, idx);
+	return 0;
+}
+
 static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 			      struct sys_reg_params *p,
 			      const struct sys_reg_desc *r)
@@ -981,7 +997,7 @@ static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 /* Macro to expand the PMEVCNTRn_EL0 register */
 #define PMU_PMEVCNTR_EL0(n)						\
 	{ PMU_SYS_REG(SYS_PMEVCNTRn_EL0(n)),				\
-	  .reset = reset_pmevcntr,					\
+	  .reset = reset_pmevcntr, .get_user = get_pmu_evcntr,		\
 	  .access = access_pmu_evcntr, .reg = (PMEVCNTR0_EL0 + n), }
 
 /* Macro to expand the PMEVTYPERn_EL0 register */
@@ -1745,7 +1761,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ PMU_SYS_REG(SYS_PMCEID1_EL0),
 	  .access = access_pmceid, .reset = NULL },
 	{ PMU_SYS_REG(SYS_PMCCNTR_EL0),
-	  .access = access_pmu_evcntr, .reset = reset_unknown, .reg = PMCCNTR_EL0 },
+	  .access = access_pmu_evcntr, .reset = reset_unknown,
+	  .reg = PMCCNTR_EL0, .get_user = get_pmu_evcntr},
 	{ PMU_SYS_REG(SYS_PMXEVTYPER_EL0),
 	  .access = access_pmu_evtyper, .reset = NULL },
 	{ PMU_SYS_REG(SYS_PMXEVCNTR_EL0),
-- 
2.39.2.722.g9855ee24e9-goog

[PATCH 2/2] KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPU

[Reiji Watanabe]

Presently, when a guest writes 1 to PMCR_EL0.{C,P}, which is WO/RAZ,
KVM saves the register value, including these bits.
When userspace reads the register using KVM_GET_ONE_REG, KVM returns
the saved register value as it is (the saved value might have these
bits set).  This could result in userspace setting these bits on the
destination during migration.  Consequently, KVM may end up resetting
the vPMU counter registers (PMCCNTR_EL0 and/or PMEVCNTR<n>_EL0) to
zero on the first KVM_RUN after migration.

Fix this by not saving those bits when a guest writes 1 to those bits.

Signed-off-by: Reiji Watanabe <reijiw@google.com>
---
 arch/arm64/kvm/pmu-emul.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index 24908400e190..a5a0a9811ddb 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -538,7 +538,9 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
 	if (!kvm_pmu_is_3p5(vcpu))
 		val &= ~ARMV8_PMU_PMCR_LP;
 
-	__vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+	/* The reset bits don't indicate any state, and shouldn't be saved. */
+	__vcpu_sys_reg(vcpu, PMCR_EL0) =
+				val & ~(ARMV8_PMU_PMCR_C | ARMV8_PMU_PMCR_P);
 
 	if (val & ARMV8_PMU_PMCR_E) {
 		kvm_pmu_enable_counter_mask(vcpu,
-- 
2.39.2.722.g9855ee24e9-goog

Re: [PATCH 1/2] KVM: arm64: PMU: Fix GET_ONE_REG for vPMC regs to return the current value

[Marc Zyngier]

On Thu, 02 Mar 2023 05:50:32 +0000,
Reiji Watanabe <reijiw@google.com> wrote:
> 
> Have KVM_GET_ONE_REG for vPMU counter (vPMC) registers (PMCCNTR_EL0
> and PMEVCNTR<n>_EL0) return the sum of the register value in the sysreg
> file and the current perf event counter value.
> 
> Values of vPMC registers are saved in sysreg files on certain occasions.
> These saved values don't represent the current values of the vPMC
> registers if the perf events for the vPMCs count events after the save.
> The current values of those registers are the sum of the sysreg file
> value and the current perf event counter value.  But, when userspace
> reads those registers (using KVM_GET_ONE_REG), KVM returns the sysreg
> file value to userspace (not the sum value).
> 
> Fix this to return the sum value for KVM_GET_ONE_REG.
> 
> Signed-off-by: Reiji Watanabe <reijiw@google.com>
> ---
>  arch/arm64/kvm/sys_regs.c | 21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index c6cbfe6b854b..c48c053d6146 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -765,6 +765,22 @@ static bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
>  	return true;
>  }
>  
> +static int get_pmu_evcntr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
> +			  u64 *val)
> +{
> +	u64 idx;
> +
> +	if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 0)
> +		/* PMCCNTR_EL0 */
> +		idx = ARMV8_PMU_CYCLE_IDX;
> +	else
> +		/* PMEVCNTRn_EL0 */
> +		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> +
> +	*val = kvm_pmu_get_counter_value(vcpu, idx);
> +	return 0;

It is a bit odd not to return an error when no PMU present, but this
is already filtered out by the top-level accessors.

> +}
> +
>  static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
>  			      struct sys_reg_params *p,
>  			      const struct sys_reg_desc *r)
> @@ -981,7 +997,7 @@ static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>  /* Macro to expand the PMEVCNTRn_EL0 register */
>  #define PMU_PMEVCNTR_EL0(n)						\
>  	{ PMU_SYS_REG(SYS_PMEVCNTRn_EL0(n)),				\
> -	  .reset = reset_pmevcntr,					\
> +	  .reset = reset_pmevcntr, .get_user = get_pmu_evcntr,		\
>  	  .access = access_pmu_evcntr, .reg = (PMEVCNTR0_EL0 + n), }
>  
>  /* Macro to expand the PMEVTYPERn_EL0 register */
> @@ -1745,7 +1761,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	{ PMU_SYS_REG(SYS_PMCEID1_EL0),
>  	  .access = access_pmceid, .reset = NULL },
>  	{ PMU_SYS_REG(SYS_PMCCNTR_EL0),
> -	  .access = access_pmu_evcntr, .reset = reset_unknown, .reg = PMCCNTR_EL0 },
> +	  .access = access_pmu_evcntr, .reset = reset_unknown,
> +	  .reg = PMCCNTR_EL0, .get_user = get_pmu_evcntr},
>  	{ PMU_SYS_REG(SYS_PMXEVTYPER_EL0),
>  	  .access = access_pmu_evtyper, .reset = NULL },
>  	{ PMU_SYS_REG(SYS_PMXEVCNTR_EL0),

Reviewed-by: Marc Zyngier <maz@kernel.org>

	M.

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

Re: [PATCH 2/2] KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPU

[Marc Zyngier]

On Thu, 02 Mar 2023 05:50:33 +0000,
Reiji Watanabe <reijiw@google.com> wrote:
> 
> Presently, when a guest writes 1 to PMCR_EL0.{C,P}, which is WO/RAZ,
> KVM saves the register value, including these bits.
> When userspace reads the register using KVM_GET_ONE_REG, KVM returns
> the saved register value as it is (the saved value might have these
> bits set).  This could result in userspace setting these bits on the
> destination during migration.  Consequently, KVM may end up resetting
> the vPMU counter registers (PMCCNTR_EL0 and/or PMEVCNTR<n>_EL0) to
> zero on the first KVM_RUN after migration.
> 
> Fix this by not saving those bits when a guest writes 1 to those bits.
> 
> Signed-off-by: Reiji Watanabe <reijiw@google.com>
> ---
>  arch/arm64/kvm/pmu-emul.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> index 24908400e190..a5a0a9811ddb 100644
> --- a/arch/arm64/kvm/pmu-emul.c
> +++ b/arch/arm64/kvm/pmu-emul.c
> @@ -538,7 +538,9 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
>  	if (!kvm_pmu_is_3p5(vcpu))
>  		val &= ~ARMV8_PMU_PMCR_LP;
>  
> -	__vcpu_sys_reg(vcpu, PMCR_EL0) = val;
> +	/* The reset bits don't indicate any state, and shouldn't be saved. */
> +	__vcpu_sys_reg(vcpu, PMCR_EL0) =
> +				val & ~(ARMV8_PMU_PMCR_C | ARMV8_PMU_PMCR_P);

nit: assignment on a single line, please.

With that,

Reviewed-by: Marc Zyngier <maz@kernel.org>

Thanks,

	M.

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

Re: [PATCH 0/2] KVM: arm64: PMU: Preserve vPMC registers properly on migration

[Marc Zyngier]

On Thu, 02 Mar 2023 05:50:31 +0000,
Reiji Watanabe <reijiw@google.com> wrote:
> 
> The series fixes two problems in preserving vPMU counter (vPMC)
> registers (PMCCNTR_EL0/PMEVCNTR<n>_EL0) during migration.
> 
> One of the problems is that KVM may not return the current values
> of the vPMC registers for KVM_GET_ONE_REG.
> 
> The other one might cause KVM to reset the vPMC registers on the
> first KVM_RUN on the destination. This is because userspace might
> save PMCR_EL0 with PMCR_EL0.{C,P} bits set on the source, and
> restore it on the destination.

This looks good to me. Can you please add the relevant Fixes: tags and
a Cc: to stable? With that, that'd be a candidate for -rc3, I think.

Thanks,

	M.

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

Re: [PATCH 1/2] KVM: arm64: PMU: Fix GET_ONE_REG for vPMC regs to return the current value

[Reiji Watanabe]

Hi Marc,

On Sun, Mar 12, 2023 at 7:57 AM Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 02 Mar 2023 05:50:32 +0000,
> Reiji Watanabe <reijiw@google.com> wrote:
> >
> > Have KVM_GET_ONE_REG for vPMU counter (vPMC) registers (PMCCNTR_EL0
> > and PMEVCNTR<n>_EL0) return the sum of the register value in the sysreg
> > file and the current perf event counter value.
> >
> > Values of vPMC registers are saved in sysreg files on certain occasions.
> > These saved values don't represent the current values of the vPMC
> > registers if the perf events for the vPMCs count events after the save.
> > The current values of those registers are the sum of the sysreg file
> > value and the current perf event counter value.  But, when userspace
> > reads those registers (using KVM_GET_ONE_REG), KVM returns the sysreg
> > file value to userspace (not the sum value).
> >
> > Fix this to return the sum value for KVM_GET_ONE_REG.
> >
> > Signed-off-by: Reiji Watanabe <reijiw@google.com>
> > ---
> >  arch/arm64/kvm/sys_regs.c | 21 +++++++++++++++++++--
> >  1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index c6cbfe6b854b..c48c053d6146 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -765,6 +765,22 @@ static bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
> >       return true;
> >  }
> >
> > +static int get_pmu_evcntr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r,
> > +                       u64 *val)
> > +{
> > +     u64 idx;
> > +
> > +     if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 0)
> > +             /* PMCCNTR_EL0 */
> > +             idx = ARMV8_PMU_CYCLE_IDX;
> > +     else
> > +             /* PMEVCNTRn_EL0 */
> > +             idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
> > +
> > +     *val = kvm_pmu_get_counter_value(vcpu, idx);
> > +     return 0;
>
> It is a bit odd not to return an error when no PMU present, but this
> is already filtered out by the top-level accessors.

Yes, exactly.

>
> > +}
> > +
> >  static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
> >                             struct sys_reg_params *p,
> >                             const struct sys_reg_desc *r)
> > @@ -981,7 +997,7 @@ static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >  /* Macro to expand the PMEVCNTRn_EL0 register */
> >  #define PMU_PMEVCNTR_EL0(n)                                          \
> >       { PMU_SYS_REG(SYS_PMEVCNTRn_EL0(n)),                            \
> > -       .reset = reset_pmevcntr,                                      \
> > +       .reset = reset_pmevcntr, .get_user = get_pmu_evcntr,          \
> >         .access = access_pmu_evcntr, .reg = (PMEVCNTR0_EL0 + n), }
> >
> >  /* Macro to expand the PMEVTYPERn_EL0 register */
> > @@ -1745,7 +1761,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> >       { PMU_SYS_REG(SYS_PMCEID1_EL0),
> >         .access = access_pmceid, .reset = NULL },
> >       { PMU_SYS_REG(SYS_PMCCNTR_EL0),
> > -       .access = access_pmu_evcntr, .reset = reset_unknown, .reg = PMCCNTR_EL0 },
> > +       .access = access_pmu_evcntr, .reset = reset_unknown,
> > +       .reg = PMCCNTR_EL0, .get_user = get_pmu_evcntr},
> >       { PMU_SYS_REG(SYS_PMXEVTYPER_EL0),
> >         .access = access_pmu_evtyper, .reset = NULL },
> >       { PMU_SYS_REG(SYS_PMXEVCNTR_EL0),
>
> Reviewed-by: Marc Zyngier <maz@kernel.org>

Thank you!
Reiji

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

Re: [PATCH 2/2] KVM: arm64: PMU: Don't save PMCR_EL0.{C,P} for the vCPU

[Reiji Watanabe]

Hi Marc,

On Sun, Mar 12, 2023 at 8:01 AM Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 02 Mar 2023 05:50:33 +0000,
> Reiji Watanabe <reijiw@google.com> wrote:
> >
> > Presently, when a guest writes 1 to PMCR_EL0.{C,P}, which is WO/RAZ,
> > KVM saves the register value, including these bits.
> > When userspace reads the register using KVM_GET_ONE_REG, KVM returns
> > the saved register value as it is (the saved value might have these
> > bits set).  This could result in userspace setting these bits on the
> > destination during migration.  Consequently, KVM may end up resetting
> > the vPMU counter registers (PMCCNTR_EL0 and/or PMEVCNTR<n>_EL0) to
> > zero on the first KVM_RUN after migration.
> >
> > Fix this by not saving those bits when a guest writes 1 to those bits.
> >
> > Signed-off-by: Reiji Watanabe <reijiw@google.com>
> > ---
> >  arch/arm64/kvm/pmu-emul.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> > index 24908400e190..a5a0a9811ddb 100644
> > --- a/arch/arm64/kvm/pmu-emul.c
> > +++ b/arch/arm64/kvm/pmu-emul.c
> > @@ -538,7 +538,9 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
> >       if (!kvm_pmu_is_3p5(vcpu))
> >               val &= ~ARMV8_PMU_PMCR_LP;
> >
> > -     __vcpu_sys_reg(vcpu, PMCR_EL0) = val;
> > +     /* The reset bits don't indicate any state, and shouldn't be saved. */
> > +     __vcpu_sys_reg(vcpu, PMCR_EL0) =
> > +                             val & ~(ARMV8_PMU_PMCR_C | ARMV8_PMU_PMCR_P);
>
> nit: assignment on a single line, please.

Yes, I fixed it in v2!

>
> With that,
>
> Reviewed-by: Marc Zyngier <maz@kernel.org>

Thank you!
Reiji

Re: [PATCH 0/2] KVM: arm64: PMU: Preserve vPMC registers properly on migration

[Reiji Watanabe]

Hi Marc,

On Sun, Mar 12, 2023 at 8:04 AM Marc Zyngier <maz@kernel.org> wrote:
>
> On Thu, 02 Mar 2023 05:50:31 +0000,
> Reiji Watanabe <reijiw@google.com> wrote:
> >
> > The series fixes two problems in preserving vPMU counter (vPMC)
> > registers (PMCCNTR_EL0/PMEVCNTR<n>_EL0) during migration.
> >
> > One of the problems is that KVM may not return the current values
> > of the vPMC registers for KVM_GET_ONE_REG.
> >
> > The other one might cause KVM to reset the vPMC registers on the
> > first KVM_RUN on the destination. This is because userspace might
> > save PMCR_EL0 with PMCR_EL0.{C,P} bits set on the source, and
> > restore it on the destination.
>
> This looks good to me. Can you please add the relevant Fixes: tags and
> a Cc: to stable? With that, that'd be a candidate for -rc3, I think.

Thank you for the review!

I posted v2, which addressed the comments above, and the comment
for the patch-2 (remove the line break).

Thank you,
Reiji



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