From: Oliver Upton <oliver.upton@linux.dev>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
maz@kernel.org, will@kernel.org, catalin.marinas@arm.com,
james.morse@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, wangzhou1@hisilicon.com,
linuxarm@huawei.com
Subject: Re: [PATCH v2] KVM: arm64: Make the exposed feature bits in AA64DFR0_EL1 writable from userspace
Date: Thu, 15 Aug 2024 10:42:22 -0700 [thread overview]
Message-ID: <Zr49_ticsFzHOJq8@linux.dev> (raw)
In-Reply-To: <20240815155954.85480-1-shameerali.kolothum.thodi@huawei.com>
On Thu, Aug 15, 2024 at 04:59:54PM +0100, Shameer Kolothum 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 differ. Add support to make this feature
> writable from userspace by setting the mask bit. While at it, set the
> mask bits for the exposed WRPs(Number of Watchpoints) as well.
> Also update the selftest to cover these fields.
>
> However we still can't make BRPs and CTX_CMPs fields writable, because
> as per ARM ARM DDI 0487K.a, section G2.8.2 Breakpoint types and
> linking of breakpoints, highest numbered breakpoints must be context aware
> breakpoints. And it will be problematic if userspace decreases the number
> of non-context aware breakpoints as it will make the context aware
> breakpoints for the guest mapped to a wrong one.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> v1 --> v2:
> Removed making BRPs and CTX_CMPs writable.
> v1: https://lore.kernel.org/all/20240813142835.77180-1-shameerali.kolothum.thodi@huawei.com/
> ---
> arch/arm64/kvm/sys_regs.c | 13 ++++++++++++-
> tools/testing/selftests/kvm/aarch64/set_id_regs.c | 2 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index c90324060436..e77cd6d1abb5 100644\x02
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2376,7 +2376,18 @@ 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 |
> + /*
> + * We can't still make BRPs and CTX_CMPx writable as highest
> + * numbered breakpoints must be context aware breakpoints(ARM ARM
> + * DDI 0487K.a, section G2.8.2 Breakpoint types and linking of
> + * breakpoints). Hence, if the number of non-context aware breakpoints
> + * for the Guest is decreased by userspace, that will be problematic
> + * as KVM will map context aware breakpoints for the vCPU to different
> + * numbered breakpoints for the pCPU.
A few minor nitpicks:
- BRPs counts the total number of breakpoints, not just the non-context
aware BRPs
- KVM doesn't do any register mapping at all, which is why we disallow
changing the breakpoints altogether
- The citation is for the AArch32 view of the debug architecture, not
AArch64.
Perhaps use this wording:
/*
* Prior to FEAT_Debugv8.9, the architecture defines context-aware
* breakpoints (CTX_CMPs) as the highest numbered breakpoints (BRPs).
* KVM does not trap + emulate the breakpoint registers, and as such
* cannot support a layout that misaligns with the underlying hardware.
* While it may be possible to describe a subset that aligns with
* hardware, just prevent changes to BRPs and CTX_CMPs altogether for
* simplicity.
*
* See DDI0487K.a, section D2.8.3 Breakpoint types and linking
* of breakpoints for more details.
*/
Besides that, LGTM:
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
> + */
> + .val = ID_AA64DFR0_EL1_DoubleLock_MASK |
> + ID_AA64DFR0_EL1_WRPs_MASK |
> + ID_AA64DFR0_EL1_PMUVer_MASK |
> ID_AA64DFR0_EL1_DebugVer_MASK, },
> ID_SANITISED(ID_AA64DFR1_EL1),
> ID_UNALLOCATED(5,2),
> diff --git a/tools/testing/selftests/kvm/aarch64/set_id_regs.c b/tools/testing/selftests/kvm/aarch64/set_id_regs.c
> index d20981663831..6edc5412abe8 100644
> --- a/tools/testing/selftests/kvm/aarch64/set_id_regs.c
> +++ b/tools/testing/selftests/kvm/aarch64/set_id_regs.c
> @@ -68,6 +68,8 @@ struct test_feature_reg {
> }
>
> static const struct reg_ftr_bits ftr_id_aa64dfr0_el1[] = {
> + S_REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64DFR0_EL1, DoubleLock, 0),
> + REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64DFR0_EL1, WRPs, 0),
> S_REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64DFR0_EL1, PMUVer, 0),
> REG_FTR_BITS(FTR_LOWER_SAFE, ID_AA64DFR0_EL1, DebugVer, ID_AA64DFR0_EL1_DebugVer_IMP),
> REG_FTR_END,
> --
> 2.45.2
>
--
Thanks,
Oliver
next prev parent reply other threads:[~2024-08-15 17:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 15:59 [PATCH v2] KVM: arm64: Make the exposed feature bits in AA64DFR0_EL1 writable from userspace Shameer Kolothum
2024-08-15 17:42 ` Oliver Upton [this message]
2024-08-16 6:37 ` Shameerali Kolothum Thodi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zr49_ticsFzHOJq8@linux.dev \
--to=oliver.upton@linux.dev \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=maz@kernel.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suzuki.poulose@arm.com \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.