From: Oliver Upton <oliver.upton@linux.dev>
To: kvmarm@lists.linux.dev
Cc: Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Oliver Upton <oliver.upton@linux.dev>
Subject: [PATCH v3 07/17] KVM: arm64: nv: Reinject traps that take effect in Host EL0
Date: Mon, 7 Oct 2024 17:45:49 +0000 [thread overview]
Message-ID: <20241007174559.1830205-8-oliver.upton@linux.dev> (raw)
In-Reply-To: <20241007174559.1830205-1-oliver.upton@linux.dev>
Wire up the other end of traps that affect host EL0 by actually
injecting them into the guest hypervisor. Skip over FGT entirely, as a
cursory glance suggests no FGT is effective in host EL0.
Note that kvm_inject_nested() is already equipped for handling
exceptions while the VM is already in a host context.
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/kvm/emulate-nested.c | 29 ++++++++++++++++++++++++----
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index a601a9305b10..bf0c48403f59 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -225,6 +225,11 @@ static inline bool is_hyp_ctxt(const struct kvm_vcpu *vcpu)
return vcpu_has_nv(vcpu) && __is_hyp_ctxt(&vcpu->arch.ctxt);
}
+static inline bool vcpu_is_host_el0(const struct kvm_vcpu *vcpu)
+{
+ return is_hyp_ctxt(vcpu) && !vcpu_is_el2(vcpu);
+}
+
/*
* The layout of SPSR for an AArch32 state is different when observed from an
* AArch64 SPSR_ELx or an AArch32 SPSR_*. This function generates the AArch32
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index e1a30d1bcd06..db3149379a4d 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),
};
struct trap_bits {
@@ -2128,11 +2131,19 @@ static u64 kvm_get_sysreg_res0(struct kvm *kvm, enum vcpu_sysreg sr)
return masks->mask[sr - __VNCR_START__].res0;
}
-static bool check_fgt_bit(struct kvm *kvm, bool is_read,
+static bool check_fgt_bit(struct kvm_vcpu *vcpu, bool is_read,
u64 val, const union trap_config tc)
{
+ struct kvm *kvm = vcpu->kvm;
enum vcpu_sysreg sr;
+ /*
+ * KVM doesn't know about any FGTs that apply to the host, and hopefully
+ * that'll remain the case.
+ */
+ if (is_hyp_ctxt(vcpu))
+ return false;
+
if (tc.pol)
return (val & BIT(tc.bit));
@@ -2209,7 +2220,15 @@ bool triage_sysreg_trap(struct kvm_vcpu *vcpu, int *sr_index)
* If we're not nesting, immediately return to the caller, with the
* sysreg index, should we have it.
*/
- if (!vcpu_has_nv(vcpu) || is_hyp_ctxt(vcpu))
+ if (!vcpu_has_nv(vcpu))
+ goto local;
+
+ /*
+ * There are a few traps that take effect InHost, but are constrained
+ * to EL0. Don't bother with computing the trap behaviour if the vCPU
+ * isn't in EL0.
+ */
+ if (is_hyp_ctxt(vcpu) && !vcpu_is_host_el0(vcpu))
goto local;
switch ((enum fgt_group_id)tc.fgt) {
@@ -2255,12 +2274,14 @@ bool triage_sysreg_trap(struct kvm_vcpu *vcpu, int *sr_index)
goto local;
}
- if (tc.fgt != __NO_FGT_GROUP__ && check_fgt_bit(vcpu->kvm, is_read,
- val, tc))
+ if (tc.fgt != __NO_FGT_GROUP__ && check_fgt_bit(vcpu, is_read, val, tc))
goto inject;
b = compute_trap_behaviour(vcpu, tc);
+ if (!(b & BEHAVE_IN_HOST_EL0) && vcpu_is_host_el0(vcpu))
+ goto local;
+
if (((b & BEHAVE_FORWARD_READ) && is_read) ||
((b & BEHAVE_FORWARD_WRITE) && !is_read))
goto inject;
--
2.47.0.rc0.187.ge670bccf7e-goog
next prev parent reply other threads:[~2024-10-07 17:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 17:45 [PATCH v3 00/17] KVM: arm64: nv: Support for EL2 PMU controls Oliver Upton
2024-10-07 17:45 ` [PATCH v3 01/17] KVM: arm64: Extend masking facility to arbitrary registers Oliver Upton
2024-10-07 17:45 ` [PATCH v3 02/17] arm64: sysreg: Migrate MDCR_EL2 definition to table Oliver Upton
2024-10-13 11:28 ` Marc Zyngier
2024-10-07 17:45 ` [PATCH v3 03/17] arm64: sysreg: Add missing definitions for ID_AA64DFR0_EL1 Oliver Upton
2024-10-07 17:45 ` [PATCH v3 04/17] KVM: arm64: Describe RES0/RES1 bits of MDCR_EL2 Oliver Upton
2024-10-13 11:40 ` Marc Zyngier
2024-10-07 17:45 ` [PATCH v3 05/17] KVM: arm64: nv: Allow coarse-grained trap combos to use complex traps Oliver Upton
2024-10-07 17:45 ` [PATCH v3 06/17] KVM: arm64: nv: Rename BEHAVE_FORWARD_ANY Oliver Upton
2024-10-07 17:45 ` Oliver Upton [this message]
2024-10-07 17:45 ` [PATCH v3 08/17] KVM: arm64: nv: Honor MDCR_EL2.{TPM, TPMCR} in Host EL0 Oliver Upton
2024-10-07 17:45 ` [PATCH v3 09/17] KVM: arm64: nv: Describe trap behaviour of MDCR_EL2.HPMN Oliver Upton
2024-10-13 12:03 ` Marc Zyngier
2024-10-07 17:45 ` [PATCH v3 10/17] KVM: arm64: nv: Advertise support for FEAT_HPMN0 Oliver Upton
2024-10-07 17:45 ` [PATCH v3 11/17] KVM: arm64: Rename kvm_pmu_valid_counter_mask() Oliver Upton
2024-10-07 17:45 ` [PATCH v3 12/17] KVM: arm64: nv: Adjust range of accessible PMCs according to HPMN Oliver Upton
2024-10-13 12:14 ` Marc Zyngier
2024-10-07 17:45 ` [PATCH v3 13/17] KVM: arm64: Add helpers to determine if PMC counts at a given EL Oliver Upton
2024-10-07 17:45 ` [PATCH v3 14/17] KVM: arm64: nv: Honor MDCR_EL2.HPME Oliver Upton
2024-10-07 17:45 ` [PATCH v3 15/17] KVM: arm64: nv: Honor MDCR_EL2.HLP Oliver Upton
2024-10-07 17:45 ` [PATCH v3 16/17] KVM: arm64: nv: Apply EL2 event filtering when in hyp context Oliver Upton
2024-10-07 17:45 ` [PATCH v3 17/17] KVM: arm64: nv: Reprogram PMU events affected by nested transition Oliver Upton
2024-10-13 12:43 ` [PATCH v3 00/17] KVM: arm64: nv: Support for EL2 PMU controls Marc Zyngier
2024-10-25 5:17 ` Anshuman Khandual
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=20241007174559.1830205-8-oliver.upton@linux.dev \
--to=oliver.upton@linux.dev \
--cc=anshuman.khandual@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--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.