From: James Morse <james.morse@arm.com> To: Alexandru Elisei <alexandru.elisei@arm.com> Cc: maz@kernel.org, linux-arm-kernel@lists.infradead.org, will@kernel.org, kvmarm@lists.cs.columbia.edu Subject: Re: [RFC PATCH v3 01/16] KVM: arm64: Initialize VCPU mdcr_el2 before loading it Date: Thu, 19 Nov 2020 16:58:08 +0000 [thread overview] Message-ID: <2058bc39-b2ea-602e-8e94-6caf470151ec@arm.com> (raw) In-Reply-To: <20201027172705.15181-2-alexandru.elisei@arm.com> Hi Alex, On 27/10/2020 17:26, Alexandru Elisei wrote: > When a VCPU is created, the kvm_vcpu struct is initialized to zero in > kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time > vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is > set to a sensible value in kvm_arm_setup_debug() later in the run loop. The > result is that KVM executes for a short time with MDCR_EL2 set to zero. > > This is mostly harmless as we don't need to trap debug and SPE register > accesses from EL1 (we're still running in the host at EL2), but we do set > MDCR_EL2.HPMN to 0 which is constrained unpredictable according to ARM DDI > 0487F.b, page D13-3620; the required behavior from the hardware in this > case is to reserve an unkown number of registers for EL2 and EL3 exclusive > use. > > Initialize mdcr_el2 in kvm_vcpu_vcpu_first_run_init(), so we can avoid the > constrained unpredictable behavior and to ensure that the MDCR_EL2 register > has the same value after each vcpu_load(), including the first time the > VCPU is run. > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c > index 7a7e425616b5..22ee448aee2b 100644 > --- a/arch/arm64/kvm/debug.c > +++ b/arch/arm64/kvm/debug.c > @@ -68,6 +68,59 @@ void kvm_arm_init_debug(void) > +static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu, u32 host_mdcr) > +{ > + bool trap_debug = !(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY); > + > + /* > + * This also clears MDCR_EL2_E2PB_MASK to disable guest access > + * to the profiling buffer. > + */ > + vcpu->arch.mdcr_el2 = host_mdcr & MDCR_EL2_HPMN_MASK; > + vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | > + MDCR_EL2_TPMS | > + MDCR_EL2_TPMCR | > + MDCR_EL2_TDRA | > + MDCR_EL2_TDOSA); > + if (vcpu->guest_debug) { > + /* Route all software debug exceptions to EL2 */ > + vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE; > + if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW) > + trap_debug = true; > + } This had me confused for a while... could you hint that this is when the guest is being 'external' debugged by the VMM? (its clear-er before this change) Thanks, James > + /* Trap debug register access */ > + if (trap_debug) > + vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA; > + > + trace_kvm_arm_set_dreg32("MDCR_EL2", vcpu->arch.mdcr_el2); > +} _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com> To: Alexandru Elisei <alexandru.elisei@arm.com> Cc: suzuki.poulose@arm.com, maz@kernel.org, linux-arm-kernel@lists.infradead.org, will@kernel.org, kvmarm@lists.cs.columbia.edu, julien.thierry.kdev@gmail.com Subject: Re: [RFC PATCH v3 01/16] KVM: arm64: Initialize VCPU mdcr_el2 before loading it Date: Thu, 19 Nov 2020 16:58:08 +0000 [thread overview] Message-ID: <2058bc39-b2ea-602e-8e94-6caf470151ec@arm.com> (raw) In-Reply-To: <20201027172705.15181-2-alexandru.elisei@arm.com> Hi Alex, On 27/10/2020 17:26, Alexandru Elisei wrote: > When a VCPU is created, the kvm_vcpu struct is initialized to zero in > kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time > vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is > set to a sensible value in kvm_arm_setup_debug() later in the run loop. The > result is that KVM executes for a short time with MDCR_EL2 set to zero. > > This is mostly harmless as we don't need to trap debug and SPE register > accesses from EL1 (we're still running in the host at EL2), but we do set > MDCR_EL2.HPMN to 0 which is constrained unpredictable according to ARM DDI > 0487F.b, page D13-3620; the required behavior from the hardware in this > case is to reserve an unkown number of registers for EL2 and EL3 exclusive > use. > > Initialize mdcr_el2 in kvm_vcpu_vcpu_first_run_init(), so we can avoid the > constrained unpredictable behavior and to ensure that the MDCR_EL2 register > has the same value after each vcpu_load(), including the first time the > VCPU is run. > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c > index 7a7e425616b5..22ee448aee2b 100644 > --- a/arch/arm64/kvm/debug.c > +++ b/arch/arm64/kvm/debug.c > @@ -68,6 +68,59 @@ void kvm_arm_init_debug(void) > +static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu, u32 host_mdcr) > +{ > + bool trap_debug = !(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY); > + > + /* > + * This also clears MDCR_EL2_E2PB_MASK to disable guest access > + * to the profiling buffer. > + */ > + vcpu->arch.mdcr_el2 = host_mdcr & MDCR_EL2_HPMN_MASK; > + vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | > + MDCR_EL2_TPMS | > + MDCR_EL2_TPMCR | > + MDCR_EL2_TDRA | > + MDCR_EL2_TDOSA); > + if (vcpu->guest_debug) { > + /* Route all software debug exceptions to EL2 */ > + vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE; > + if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW) > + trap_debug = true; > + } This had me confused for a while... could you hint that this is when the guest is being 'external' debugged by the VMM? (its clear-er before this change) Thanks, James > + /* Trap debug register access */ > + if (trap_debug) > + vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA; > + > + trace_kvm_arm_set_dreg32("MDCR_EL2", vcpu->arch.mdcr_el2); > +} _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-19 16:58 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-27 17:26 [RFC PATCH v3 00/16] KVM: arm64: Add Statistical Profiling Extension (SPE) support Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 01/16] KVM: arm64: Initialize VCPU mdcr_el2 before loading it Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-11-19 16:58 ` James Morse [this message] 2020-11-19 16:58 ` James Morse 2020-12-02 14:25 ` Alexandru Elisei 2020-12-02 14:25 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 02/16] dt-bindings: ARM SPE: Highlight the need for PPI partitions on heterogeneous systems Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 03/16] KVM: arm64: Hide SPE from guests Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 04/16] arm64: Introduce CPU SPE feature Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-11-19 16:58 ` James Morse 2020-11-19 16:58 ` James Morse 2020-12-02 14:29 ` Alexandru Elisei 2020-12-02 14:29 ` Alexandru Elisei 2020-12-02 17:23 ` Will Deacon 2020-12-02 17:23 ` Will Deacon 2020-12-03 10:07 ` Alexandru Elisei 2020-12-03 10:07 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 05/16] KVM: arm64: Introduce VCPU " Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 06/16] KVM: arm64: Introduce SPE primitives Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-11-19 16:58 ` James Morse 2020-11-19 16:58 ` James Morse 2020-12-02 15:13 ` Alexandru Elisei 2020-12-02 15:13 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 07/16] KVM: arm64: Define SPE data structure for each VCPU Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 08/16] KVM: arm64: Add a new VCPU device control group for SPE Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-11-05 9:58 ` Haibo Xu 2020-11-05 9:58 ` Haibo Xu 2020-12-02 15:20 ` Alexandru Elisei 2020-12-02 15:20 ` Alexandru Elisei 2020-11-19 16:58 ` James Morse 2020-11-19 16:58 ` James Morse 2020-12-02 16:28 ` Alexandru Elisei 2020-12-02 16:28 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 09/16] KVM: arm64: Use separate function for the mapping size in user_mem_abort() Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-11-05 10:01 ` Haibo Xu 2020-11-05 10:01 ` Haibo Xu 2020-12-02 16:29 ` Alexandru Elisei 2020-12-02 16:29 ` Alexandru Elisei 2020-10-27 17:26 ` [RFC PATCH v3 10/16] KVM: arm64: Add a new VM device control group for SPE Alexandru Elisei 2020-10-27 17:26 ` Alexandru Elisei 2020-11-05 10:10 ` Haibo Xu 2020-11-05 10:10 ` Haibo Xu 2020-12-02 16:35 ` Alexandru Elisei 2020-12-02 16:35 ` Alexandru Elisei 2020-11-19 16:59 ` James Morse 2020-11-19 16:59 ` James Morse 2021-03-23 14:27 ` Alexandru Elisei 2021-03-23 14:27 ` Alexandru Elisei 2020-10-27 17:27 ` [RFC PATCH v3 11/16] KVM: arm64: Add SPE system registers to VCPU context Alexandru Elisei 2020-10-27 17:27 ` Alexandru Elisei 2020-10-27 17:27 ` [RFC PATCH v3 12/16] KVM: arm64: VHE: Clear MDCR_EL2.E2PB in vcpu_put() Alexandru Elisei 2020-10-27 17:27 ` Alexandru Elisei 2020-10-27 17:27 ` [RFC PATCH v3 13/16] KVM: arm64: Switch SPE context on VM entry/exit Alexandru Elisei 2020-10-27 17:27 ` Alexandru Elisei 2020-10-27 17:27 ` [RFC PATCH v3 14/16] KVM: arm64: Emulate SPE buffer management interrupt Alexandru Elisei 2020-10-27 17:27 ` Alexandru Elisei 2020-10-27 17:27 ` [RFC PATCH v3 15/16] KVM: arm64: Enable SPE for guests Alexandru Elisei 2020-10-27 17:27 ` Alexandru Elisei 2020-10-27 17:27 ` [RFC PATCH v3 16/16] Documentation: arm64: Document ARM Neoverse-N1 erratum #1688567 Alexandru Elisei 2020-10-27 17:27 ` Alexandru Elisei
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=2058bc39-b2ea-602e-8e94-6caf470151ec@arm.com \ --to=james.morse@arm.com \ --cc=alexandru.elisei@arm.com \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=maz@kernel.org \ --cc=will@kernel.org \ /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: linkBe 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.