| Message ID | 20250220134907.554085-3-maz@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | KVM: arm64: NV userspace ABI | expand |
Hi Marc, On Thu, 20 Feb 2025, Marc Zyngier wrote: > Since our take on FEAT_NV is to only support FEAT_NV2, we should > never expose ID_AA64MMFR2_EL1.NV to a guest nor userspace. > > Make sure we mask this field for good. > > Signed-off-by: Marc Zyngier <maz@kernel.org> > --- > arch/arm64/kvm/sys_regs.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 82430c1e1dd02..9f10dbd26e348 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1627,6 +1627,7 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu, > break; > case SYS_ID_AA64MMFR2_EL1: > val &= ~ID_AA64MMFR2_EL1_CCIDX_MASK; > + val &= ~ID_AA64MMFR2_EL1_NV; > break; This would cause issues when you update the host kernel while keeping the guests register state. Could we allow to write (but ignore) the previously valid value? Like it was handled in: 6685f5d572c2 KVM: arm64: Disable MPAM visibility by default and ignore VMM writes Sebastian
On Thu, 20 Feb 2025 17:36:35 +0000, Sebastian Ott <sebott@redhat.com> wrote: > > Hi Marc, > > On Thu, 20 Feb 2025, Marc Zyngier wrote: > > Since our take on FEAT_NV is to only support FEAT_NV2, we should > > never expose ID_AA64MMFR2_EL1.NV to a guest nor userspace. > > > > Make sure we mask this field for good. > > > > Signed-off-by: Marc Zyngier <maz@kernel.org> > > --- > > arch/arm64/kvm/sys_regs.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 82430c1e1dd02..9f10dbd26e348 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -1627,6 +1627,7 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu, > > break; > > case SYS_ID_AA64MMFR2_EL1: > > val &= ~ID_AA64MMFR2_EL1_CCIDX_MASK; > > + val &= ~ID_AA64MMFR2_EL1_NV; > > break; > > This would cause issues when you update the host kernel while keeping the > guests register state. Could we allow to write (but ignore) the previously > valid value? Like it was handled in: > 6685f5d572c2 KVM: arm64: Disable MPAM visibility by default and ignore VMM writes Yeah, this falls into the same "shouldn't have exposed this the first place" bucket. Annoying. Something like the diff below? M. diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 2e14562b5841f..87269de31a642 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1946,6 +1946,22 @@ static int set_id_aa64pfr1_el1(struct kvm_vcpu *vcpu, return set_id_reg(vcpu, rd, user_val); } +static int set_id_aa64mmfr2_el1(struct kvm_vcpu *vcpu, + const struct sys_reg_desc *rd, u64 user_val) +{ + u64 hw_val = read_sanitised_ftr_reg(SYS_ID_AA64MMFR2_EL1); + u64 nv_mask = ID_AA64MMFR2_EL1_NV_MASK; + + /* + * We made the mistake to expose the now deprecated NV field, + * so allow userspace to write it, but silently ignore it. + */ + if ((hw_val & nv_mask) == (user_val & nv_mask)) + user_val &= ~nv_mask; + + 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) { @@ -2730,7 +2746,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { ID_AA64MMFR1_EL1_XNX | ID_AA64MMFR1_EL1_VH | ID_AA64MMFR1_EL1_VMIDBits)), - ID_WRITABLE(ID_AA64MMFR2_EL1, ~(ID_AA64MMFR2_EL1_RES0 | + ID_FILTERED(ID_AA64MMFR2_EL1, + id_aa64mmfr2_el1, ~(ID_AA64MMFR2_EL1_RES0 | ID_AA64MMFR2_EL1_EVT | ID_AA64MMFR2_EL1_FWB | ID_AA64MMFR2_EL1_IDS |
On Thu, 20 Feb 2025, Marc Zyngier wrote: > On Thu, 20 Feb 2025 17:36:35 +0000, > Sebastian Ott <sebott@redhat.com> wrote: >> On Thu, 20 Feb 2025, Marc Zyngier wrote: >>> Since our take on FEAT_NV is to only support FEAT_NV2, we should >>> never expose ID_AA64MMFR2_EL1.NV to a guest nor userspace. >>> >>> Make sure we mask this field for good. >>> >>> Signed-off-by: Marc Zyngier <maz@kernel.org> >>> --- >>> arch/arm64/kvm/sys_regs.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c >>> index 82430c1e1dd02..9f10dbd26e348 100644 >>> --- a/arch/arm64/kvm/sys_regs.c >>> +++ b/arch/arm64/kvm/sys_regs.c >>> @@ -1627,6 +1627,7 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu, >>> break; >>> case SYS_ID_AA64MMFR2_EL1: >>> val &= ~ID_AA64MMFR2_EL1_CCIDX_MASK; >>> + val &= ~ID_AA64MMFR2_EL1_NV; >>> break; >> >> This would cause issues when you update the host kernel while keeping the >> guests register state. Could we allow to write (but ignore) the previously >> valid value? Like it was handled in: >> 6685f5d572c2 KVM: arm64: Disable MPAM visibility by default and ignore VMM writes > > Yeah, this falls into the same "shouldn't have exposed this the first > place" bucket. Annoying. Something like the diff below? Yes, thanks!
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 82430c1e1dd02..9f10dbd26e348 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1627,6 +1627,7 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu, break; case SYS_ID_AA64MMFR2_EL1: val &= ~ID_AA64MMFR2_EL1_CCIDX_MASK; + val &= ~ID_AA64MMFR2_EL1_NV; break; case SYS_ID_AA64MMFR3_EL1: val &= ID_AA64MMFR3_EL1_TCRX | ID_AA64MMFR3_EL1_S1POE |
Since our take on FEAT_NV is to only support FEAT_NV2, we should never expose ID_AA64MMFR2_EL1.NV to a guest nor userspace. Make sure we mask this field for good. Signed-off-by: Marc Zyngier <maz@kernel.org> --- arch/arm64/kvm/sys_regs.c | 1 + 1 file changed, 1 insertion(+)