[PATCH v2] KVM: arm64: Make L1Ip feature in CTR_EL0 writable from userspace
Shameerali Kolothum Thodi
shameerali.kolothum.thodi at huawei.com
Thu Nov 7 01:05:55 PST 2024
Hi Oliver,
A gentle ping on this. I think it still applies cleanly on top of Joey's v6 of MPAM
Hide series.
Thanks,
Shameer
> -----Original Message-----
> From: linux-arm-kernel <linux-arm-kernel-bounces at lists.infradead.org> On
> Behalf Of Shameer Kolothum
> Sent: Tuesday, October 22, 2024 8:40 AM
> To: kvmarm at lists.linux.dev; maz at kernel.org; oliver.upton at linux.dev
> Cc: james.morse at arm.com; joey.gouly at arm.com;
> suzuki.poulose at arm.com; sebott at redhat.com; yuzenghui
> <yuzenghui at huawei.com>; Wangzhou (B) <wangzhou1 at hisilicon.com>;
> linux-arm-kernel at lists.infradead.org; Linuxarm <linuxarm at huawei.com>
> Subject: [PATCH v2] KVM: arm64: Make L1Ip feature in CTR_EL0 writable
> from userspace
>
> Only allow userspace to set VIPT(0b10) or PIPT(0b11) for L1Ip based on
> what hardware reports as both AIVIVT (0b01) and VPIPT (0b00) are
> documented as reserved.
>
> Using a VIPT for Guest where hardware reports PIPT may lead to over
> invalidation, but is still correct. Hence, we can allow downgrading
> PIPT to VIPT, but not the other way around.
>
> Reviewed-by: Sebastian Ott <sebott at redhat.com>
> Reviewed-by: Marc Zyngier <maz at kernel.org>
> Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi at huawei.com>
> ---
> v1:
> https://lore.kernel.org/kvmarm/20241017085925.40532-1-
> shameerali.kolothum.thodi at huawei.com/
>
> Changes from v1:
> -As per Marc's suggestion modified the way set_ctr_el0() restricted
> the write which implied ordered values for the types. Instead
> explicitly listed all possible policy types.
> -Added R-by tags(Thanks!).
>
> Thanks,
> Shameer
> ---
> arch/arm64/kvm/sys_regs.c | 38 ++++++++++++++++++++++++++++++++++---
> -
> 1 file changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index d97ccf1c1558..0a0f336b0edd 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1872,6 +1872,34 @@ static int set_id_aa64pfr1_el1(struct kvm_vcpu
> *vcpu,
> return set_id_reg(vcpu, rd, user_val);
> }
>
> +static int set_ctr_el0(struct kvm_vcpu *vcpu,
> + const struct sys_reg_desc *rd, u64 user_val)
> +{
> + u8 user_L1Ip = SYS_FIELD_GET(CTR_EL0, L1Ip, user_val);
> +
> + /*
> + * Both AIVIVT (0b01) and VPIPT (0b00) are documented as reserved.
> + * Hence only allow to set VIPT(0b10) or PIPT(0b11) for L1Ip based
> + * on what hardware reports.
> + *
> + * Using a VIPT software model on PIPT will lead to over
> invalidation,
> + * but still correct. Hence, we can allow downgrading PIPT to VIPT,
> + * but not the other way around. This is handled via
> arm64_ftr_safe_value()
> + * as CTR_EL0 ftr_bits has L1Ip field with type FTR_EXACT and safe
> value
> + * set as VIPT.
> + */
> + switch (user_L1Ip) {
> + case CTR_EL0_L1Ip_RESERVED_VPIPT:
> + case CTR_EL0_L1Ip_RESERVED_AIVIVT:
> + return -EINVAL;
> + case CTR_EL0_L1Ip_VIPT:
> + case CTR_EL0_L1Ip_PIPT:
> + return set_id_reg(vcpu, rd, user_val);
> + default:
> + return -ENOENT;
> + }
> +}
> +
> /*
> * cpufeature ID register user accessors
> *
> @@ -2614,10 +2642,12 @@ static const struct sys_reg_desc sys_reg_descs[]
> = {
> { SYS_DESC(SYS_CCSIDR2_EL1), undef_access },
> { SYS_DESC(SYS_SMIDR_EL1), undef_access },
> { SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown,
> CSSELR_EL1 },
> - ID_WRITABLE(CTR_EL0, CTR_EL0_DIC_MASK |
> - CTR_EL0_IDC_MASK |
> - CTR_EL0_DminLine_MASK |
> - CTR_EL0_IminLine_MASK),
> + ID_FILTERED(CTR_EL0, ctr_el0,
> + CTR_EL0_DIC_MASK |
> + CTR_EL0_IDC_MASK |
> + CTR_EL0_DminLine_MASK |
> + CTR_EL0_L1Ip_MASK |
> + CTR_EL0_IminLine_MASK),
> { SYS_DESC(SYS_SVCR), undef_access, reset_val, SVCR, 0, .visibility =
> sme_visibility },
> { SYS_DESC(SYS_FPMR), undef_access, reset_val, FPMR, 0, .visibility =
> fp8_visibility },
>
> --
> 2.45.2
>
More information about the linux-arm-kernel
mailing list