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