[PATCH] KVM: arm64: Make the exposed feature bits in AA64DFR0_EL1 writable from userspace
Marc Zyngier
maz at kernel.org
Tue Aug 13 11:20:55 PDT 2024
On Tue, 13 Aug 2024 15:28:35 +0100,
Shameer Kolothum <shameerali.kolothum.thodi at huawei.com> wrote:
>
> KVM exposes the OS double lock feature bit to Guests but returns
> RAZ/WI on Guest OSDLR_EL1 access. This breaks Guest migration between
> systems where this feature support differ. Add support to make this
> feature writable from userspace by setting the mask bit. While at it,
> set the mask bits for other exposed features in the AA64DFR0_EL1
> register as well.
>
> Also update the selftest to cover these fields.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
> ---
> This is based on the discussion here(Thanks to Oliver),
> https://lore.kernel.org/all/ZrVSlbVwnaMDShah@linux.dev/
> ---
> arch/arm64/kvm/sys_regs.c | 6 +++++-
> tools/testing/selftests/kvm/aarch64/set_id_regs.c | 4 ++++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index c90324060436..adb49d681052 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2376,7 +2376,11 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> .get_user = get_id_reg,
> .set_user = set_id_aa64dfr0_el1,
> .reset = read_sanitised_id_aa64dfr0_el1,
> - .val = ID_AA64DFR0_EL1_PMUVer_MASK |
> + .val = ID_AA64DFR0_EL1_DoubleLock_MASK |
> + ID_AA64DFR0_EL1_CTX_CMPs_MASK |
> + ID_AA64DFR0_EL1_WRPs_MASK |
> + ID_AA64DFR0_EL1_BRPs_MASK |
I think this is going to cause some troubles.
The issue is that context-aware breakpoints are the highest-numbered
breakpoints, right after the normal breakpoints (D2.8.3 "Breakpoint
types and linking of breakpoints"). So if you reduce the number of
normal breakpoints, you shift the context-aware ones down, and
everything breaks.
I really don't see how you can safely do that without completely
changing the way we handle the debug registers.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list