From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvmarm@lists.linux.dev, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
Subject: Re: [PATCH v2 04/12] KVM: arm64: nv: Add support for describing traps that affect Host EL0
Date: Tue, 27 Aug 2024 17:24:52 +0100 [thread overview]
Message-ID: <86le0ivsq3.wl-maz@kernel.org> (raw)
In-Reply-To: <20240827002235.1753237-5-oliver.upton@linux.dev>
On Tue, 27 Aug 2024 01:22:27 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
>
> The EL2 PMU trap controls are rather annoying, because they take effect
> for *host* EL0 in addition to the guest. Set up some basic support for
> describing EL2 traps that affect host EL0.
>
> Do so by describing trap bits that can take effect in host EL0. Preserve
> the early return for most hyp context traps by taking a bit out of the
> trap_config value to indicate if the trap might take effect InHost.
>
> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> ---
> arch/arm64/kvm/emulate-nested.c | 37 ++++++++++++++++++++++++++++++---
> 1 file changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index 26d32f308dd3..b9f3e19a1b96 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -20,6 +20,9 @@ enum trap_behaviour {
> BEHAVE_FORWARD_READ = BIT(0),
> BEHAVE_FORWARD_WRITE = BIT(1),
> BEHAVE_FORWARD_RW = BEHAVE_FORWARD_READ | BEHAVE_FORWARD_WRITE,
> +
> + /* Traps that take effect in Host EL0, this is rare! */
> + BEHAVE_IN_HOST_EL0 = BIT(2),
Do we need to distinguish reads from writes here? There are precedents
with things like TVM/TRVM, though not affecting EL0.
> };
>
> struct trap_bits {
> @@ -478,7 +481,8 @@ static const complex_condition_check ccc[] = {
> * [20] trap polarity (1 bit)
> * [25:21] FG filter (5 bits)
> * [35:26] Main SysReg table index (10 bits)
> - * [62:36] Unused (27 bits)
> + * [36] Trap applies to Host EL0 (1 bit)
> + * [62:37] Unused (26 bits)
> * [63] RES0 - Must be zero, as lost on insertion in the xarray
> */
> #define TC_CGT_BITS 10
> @@ -495,7 +499,8 @@ union trap_config {
> unsigned long pol:1; /* Polarity */
> unsigned long fgf:TC_FGF_BITS; /* Fine Grained Filter */
> unsigned long sri:TC_SRI_BITS; /* SysReg Index */
> - unsigned long unused:27; /* Unused, should be zero */
> + unsigned long in_host_el0:1; /* Applies to Host EL0 */
I'm a bit confused about the meaning of this new bit. If something
applies to a Host EL0 access, we already have the information as part
of the coarse grained traps. Why do we need something extra?
I understand that it is used as some form of summary information and
avoids looking at the CGT chain, but this also muddies the purpose of
the trap_config word, because this doesn't describe *why* we have
trapped.
It's not really a big deal, as we have plenty of spare bits so far,
but I find it a bit jarring.
> + unsigned long unused:26; /* Unused, should be zero */
> unsigned long mbz:1; /* Must Be Zero */
> };
> };
> @@ -1875,6 +1880,28 @@ static u32 encoding_next(u32 encoding)
> return sys_reg(op0 + 1, 0, 0, 0, 0);
> }
>
> +static bool trap_effective_in_host_el0(const enum cgt_group_id id)
> +{
> + switch (id) {
> + case __RESERVED__ ... __MULTIPLE_CONTROL_BITS__ - 1:
> + return coarse_trap_bits[id].behaviour & BEHAVE_IN_HOST_EL0;
> + case __MULTIPLE_CONTROL_BITS__ ... __COMPLEX_CONDITIONS__ - 1: {
> + const enum cgt_group_id *cgids;
> + int i;
> +
> + cgids = coarse_control_combo[id - __MULTIPLE_CONTROL_BITS__];
> + for (i = 0; cgids[i] != __RESERVED__; i++)
> + if (trap_effective_in_host_el0(cgids[i]))
> + return true;
> +
> + return false;
> + }
> + /* Just treat complex traps as InHost for now. */
s/InHost/InHost-capable/
> + default:
> + return true;
> + }
> +}
> +
> int __init populate_nv_trap_config(void)
> {
> int ret = 0;
> @@ -1886,13 +1913,17 @@ int __init populate_nv_trap_config(void)
>
> for (int i = 0; i < ARRAY_SIZE(encoding_to_cgt); i++) {
> const struct encoding_to_trap_config *cgt = &encoding_to_cgt[i];
> + union trap_config tc = cgt->tc;
> void *prev;
>
> - if (cgt->tc.val & BIT(63)) {
> + if (tc.val & BIT(63)) {
> kvm_err("CGT[%d] has MBZ bit set\n", i);
> ret = -EINVAL;
> }
>
> + if (trap_effective_in_host_el0(tc.cgt))
> + tc.in_host_el0 = true;
nit: do a direct assignment without the test.
> +
> for (u32 enc = cgt->encoding; enc <= cgt->end; enc = encoding_next(enc)) {
> prev = xa_store(&sr_forward_xa, enc,
> xa_mk_value(cgt->tc.val), GFP_KERNEL);
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-08-27 16:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 0:22 [PATCH v2 00/12] KVM: arm64: nv: More complete support for FEAT_PMUv3 Oliver Upton
2024-08-27 0:22 ` [PATCH v2 01/12] KVM: arm64: Rename kvm_pmu_valid_counter_mask() Oliver Upton
2024-08-27 0:22 ` [PATCH v2 02/12] KVM: arm64: nv: Adjust range of accessible PMCs according to HPMN Oliver Upton
2024-08-27 0:22 ` [PATCH v2 03/12] KVM: arm64: nv: Rename BEHAVE_FORWARD_ANY Oliver Upton
2024-08-27 0:22 ` [PATCH v2 04/12] KVM: arm64: nv: Add support for describing traps that affect Host EL0 Oliver Upton
2024-08-27 16:24 ` Marc Zyngier [this message]
2024-08-27 0:22 ` [PATCH v2 05/12] KVM: arm64: nv: Reinject traps that take effect in " Oliver Upton
2024-08-27 0:22 ` [PATCH v2 06/12] KVM: arm64: nv: Honor MDCR_EL2.{TPM, TPMCR} " Oliver Upton
2024-08-27 0:22 ` [PATCH v2 07/12] KVM: arm64: nv: Allow coarse-grained trap combos to use complex traps Oliver Upton
2024-08-27 0:22 ` [PATCH v2 08/12] KVM: arm64: nv: Describe trap behaviour of MDCR_EL2.HPMN Oliver Upton
2024-08-27 0:22 ` [PATCH v2 09/12] KVM: arm64: nv: Advertise support for FEAT_HPMN0 Oliver Upton
2024-08-27 16:40 ` Marc Zyngier
2024-08-27 0:22 ` [PATCH v2 10/12] KVM: arm64: Add helpers to determine if PMC counts at a given EL Oliver Upton
2024-08-27 0:22 ` [PATCH v2 11/12] KVM: arm64: nv: Honor NSH filter when in hyp context Oliver Upton
2024-08-27 0:22 ` [PATCH v2 12/12] KVM: arm64: nv: Reprogram PMU events affected by nested transition Oliver Upton
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=86le0ivsq3.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=gankulkarni@os.amperecomputing.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--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.