Hi Marc,
On Fri, Aug 5, 2022 at 6:58 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> Allow userspace to write ID_AA64DFR0_EL1, on the condition that only
> the PMUver field can be altered and be at most the one that was
> initially computed for the guest.
>
> Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
> ---
> arch/arm64/kvm/sys_regs.c | 35 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 55451f49017c..c0595f31dab8 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1236,6 +1236,38 @@ static int set_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
> return 0;
> }
>
> +static int set_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
> + const struct sys_reg_desc *rd,
> + u64 val)
The function prototype doesn't appear to be right as the
set_user of sys_reg_desc().
---
[From sys_regs.h]
[sys_regs.h]
int (*set_user)(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
const struct kvm_one_reg *reg, void __user *uaddr);
---
> +{
> + u8 pmuver, host_pmuver;
> +
> + host_pmuver = kvm_arm_pmu_get_host_pmuver();
> +
> + /*
> + * Allow AA64DFR0_EL1.PMUver to be set from userspace as long
> + * as it doesn't promise more than what the HW gives us. We
> + * don't allow an IMPDEF PMU though.
> + */
> + pmuver = FIELD_GET(ARM64_FEATURE_MASK(ID_AA64DFR0_PMUVER), val);
> + if (pmuver == ID_AA64DFR0_PMUVER_IMP_DEF || pmuver > host_pmuver)
> + return -EINVAL;
As mentioned in my comments for the patch-6, the vCPU's PMUVER could
currently be IMP_DEF. So, with this IMP_DEF checking, a guest with
IMP_DEF PMU cannot be migrated to a newer KVM host.
Do we need to tolerate writes of IMP_DEF for compatibility ?
Oliver originally point this out for my ID register series, and
my V6 or newer series tried to not return an error for this by
ignoring the user requested IMP_DEF when PMU is not enabled for
the vCPU (Instead, the field is set to 0x0).
https://lore.kernel.org/all/20220419065544.3616948-16-reijiw@xxxxxxxxxx/
Thank you,
Reiji
> +
> + /* We already have a PMU, don't try to disable it... */
> + if (kvm_vcpu_has_pmu(vcpu) && pmuver == 0)
> + return -EINVAL;
> +
> + /* We can only differ with PMUver, and anything else is an error */
> + val ^= read_id_reg(vcpu, rd, false);
> + val &= ~(0xFUL << ID_AA64DFR0_PMUVER_SHIFT);
> + if (val)
> + return -EINVAL;
> +
> + vcpu->kvm->arch.dfr0_pmuver = pmuver;
> +
> + return 0;
> +}
> +
> /*
> * cpufeature ID register user accessors
> *
> @@ -1510,7 +1542,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> ID_UNALLOCATED(4,7),
>
> /* CRm=5 */
> - ID_SANITISED(ID_AA64DFR0_EL1),
> + { SYS_DESC(SYS_ID_AA64DFR0_EL1), .access = access_id_reg,
> + .get_user = get_id_reg, .set_user = set_id_aa64dfr0_el1, },
> ID_SANITISED(ID_AA64DFR1_EL1),
> ID_UNALLOCATED(5,2),
> ID_UNALLOCATED(5,3),
> --
> 2.34.1
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@xxxxxxxxxxxxxxxxxxxxx
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
