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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox