From: "Alex Bennée" <alex.bennee@linaro.org>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Okamoto Takayuki <tokamoto@jp.fujitsu.com>,
Christoffer Dall <cdall@kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 13/23] KVM: arm64/sve: Context switch the SVE registers
Date: Mon, 19 Nov 2018 16:36:01 +0000 [thread overview]
Message-ID: <87sgzxhvny.fsf@linaro.org> (raw)
In-Reply-To: <1538141967-15375-14-git-send-email-Dave.Martin@arm.com>
Dave Martin <Dave.Martin@arm.com> writes:
> In order to give each vcpu its own view of the SVE registers, this
> patch adds context storage via a new sve_state pointer in struct
> vcpu_arch. An additional member sve_max_vl is also added for each
> vcpu, to determine the maximum vector length visible to the guest
> and thus the value to be configured in ZCR_EL2.LEN while the is
> active. This also determines the layout and size of the storage in
> sve_state, which is read and written by the same backend functions
> that are used for context-switching the SVE state for host tasks.
>
> On SVE-enabled vcpus, SVE access traps are now handled by switching
> in the vcpu's SVE context and disabling the trap before returning
> to the guest. On other vcpus, the trap is not handled and an exit
> back to the host occurs, where the handle_sve() fallback path
> reflects an undefined instruction exception back to the guest,
> consistently with the behaviour of non-SVE-capable hardware (as was
> done unconditionally prior to this patch).
>
> No SVE handling is added on non-VHE-only paths, since VHE is an
> architectural and Kconfig prerequisite of SVE.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> ---
>
> Changes since RFCv1:
>
> * Add a if_sve () helper macro to efficiently skip or optimise out
> SVE conditional support code for the SVE-unsupported case. This
> reduces the verbose boilerplate at the affected sites.
>
> * In the style of sve_pffr(), a vcpu_sve_pffr() helper is added to
> provide the FFR anchor pointer for sve_load_state() in the hyp switch
> code. This help avoid some open-coded pointer mungeing which is not
> very readable.
>
> * The condition for calling __hyp_switch_fpsimd() is abstracted for
> better readability.
> ---
> arch/arm64/include/asm/kvm_host.h | 6 ++++
> arch/arm64/kvm/fpsimd.c | 5 +--
> arch/arm64/kvm/hyp/switch.c | 71 ++++++++++++++++++++++++++++++---------
> 3 files changed, 65 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 76cbb95e..8e9cd43 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -210,6 +210,8 @@ typedef struct kvm_cpu_context kvm_cpu_context_t;
>
> struct kvm_vcpu_arch {
> struct kvm_cpu_context ctxt;
> + void *sve_state;
> + unsigned int sve_max_vl;
>
> /* HYP configuration */
> u64 hcr_el2;
> @@ -302,6 +304,10 @@ struct kvm_vcpu_arch {
> bool sysregs_loaded_on_cpu;
> };
>
> +/* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
> +#define vcpu_sve_pffr(vcpu) ((void *)((char *)((vcpu)->arch.sve_state) + \
> + sve_ffr_offset((vcpu)->arch.sve_max_vl)))
> +
> /* vcpu_arch flags field values: */
> #define KVM_ARM64_DEBUG_DIRTY (1 << 0)
> #define KVM_ARM64_FP_ENABLED (1 << 1) /* guest FP regs loaded */
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 29e5585..3474388 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -86,10 +86,11 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
>
> if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED) {
> fpsimd_bind_state_to_cpu(&vcpu->arch.ctxt.gp_regs.fp_regs,
> - NULL, sve_max_vl);
> + vcpu->arch.sve_state,
> + vcpu->arch.sve_max_vl);
>
> clear_thread_flag(TIF_FOREIGN_FPSTATE);
> - clear_thread_flag(TIF_SVE);
> + update_thread_flag(TIF_SVE, vcpu_has_sve(vcpu));
> }
> }
>
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 085ed06..9941349 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -98,7 +98,10 @@ static void activate_traps_vhe(struct kvm_vcpu *vcpu)
> val = read_sysreg(cpacr_el1);
> val |= CPACR_EL1_TTA;
> val &= ~CPACR_EL1_ZEN;
> - if (!update_fp_enabled(vcpu)) {
> + if (update_fp_enabled(vcpu)) {
> + if (vcpu_has_sve(vcpu))
> + val |= CPACR_EL1_ZEN;
> + } else {
> val &= ~CPACR_EL1_FPEN;
> __activate_traps_fpsimd32(vcpu);
> }
> @@ -332,16 +335,29 @@ static bool __hyp_text __skip_instr(struct kvm_vcpu *vcpu)
> }
> }
>
> -static bool __hyp_text __hyp_switch_fpsimd(struct kvm_vcpu *vcpu)
> +/*
> + * if () with a gating check for SVE support to minimise branch
> + * mispredictions in non-SVE systems.
> + * (system_supports_sve() is resolved at build time or via a static key.)
> + */
> +#define if_sve(cond) if (system_supports_sve() && (cond))
> +
> +static bool __hyp_text __hyp_switch_fpsimd(struct kvm_vcpu *vcpu,
> + bool guest_has_sve)
> {
> struct user_fpsimd_state *host_fpsimd = vcpu->arch.host_fpsimd_state;
>
> - if (has_vhe())
> - write_sysreg(read_sysreg(cpacr_el1) | CPACR_EL1_FPEN,
> - cpacr_el1);
> - else
> + if (has_vhe()) {
> + u64 reg = read_sysreg(cpacr_el1) | CPACR_EL1_FPEN;
> +
> + if_sve (guest_has_sve)
> + reg |= CPACR_EL1_ZEN;
> +
> + write_sysreg(reg, cpacr_el1);
> + } else {
> write_sysreg(read_sysreg(cptr_el2) & ~(u64)CPTR_EL2_TFP,
> cptr_el2);
> + }
>
> isb();
>
> @@ -350,8 +366,7 @@ static bool __hyp_text __hyp_switch_fpsimd(struct kvm_vcpu *vcpu)
> * In the SVE case, VHE is assumed: it is enforced by
> * Kconfig and kvm_arch_init().
> */
> - if (system_supports_sve() &&
> - (vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE)) {
> + if_sve (vcpu->arch.flags & KVM_ARM64_HOST_SVE_IN_USE) {
> struct thread_struct *thread = container_of(
> host_fpsimd,
> struct thread_struct, uw.fpsimd_state);
> @@ -364,11 +379,14 @@ static bool __hyp_text __hyp_switch_fpsimd(struct kvm_vcpu *vcpu)
> vcpu->arch.flags &= ~KVM_ARM64_FP_HOST;
> }
>
> - __fpsimd_restore_state(&vcpu->arch.ctxt.gp_regs.fp_regs);
> -
> - if (system_supports_sve() &&
> - vcpu->arch.flags & KVM_ARM64_GUEST_HAS_SVE)
> + if_sve (guest_has_sve) {
> + sve_load_state(vcpu_sve_pffr(vcpu),
> + &vcpu->arch.ctxt.gp_regs.fp_regs.fpsr,
> + sve_vq_from_vl(vcpu->arch.sve_max_vl) - 1);
> write_sysreg_s(vcpu->arch.ctxt.sys_regs[ZCR_EL1], SYS_ZCR_EL12);
> + } else {
> + __fpsimd_restore_state(&vcpu->arch.ctxt.gp_regs.fp_regs);
> + }
>
> /* Skip restoring fpexc32 for AArch64 guests */
> if (!(read_sysreg(hcr_el2) & HCR_RW))
> @@ -380,6 +398,26 @@ static bool __hyp_text __hyp_switch_fpsimd(struct kvm_vcpu *vcpu)
> return true;
> }
>
> +static inline bool __hyp_text __hyp_trap_is_fpsimd(struct kvm_vcpu *vcpu,
> + bool guest_has_sve)
> +{
> +
> + u8 trap_class;
> +
> + if (!system_supports_fpsimd())
> + return false;
> +
> + trap_class = kvm_vcpu_trap_get_class(vcpu);
> +
> + if (trap_class == ESR_ELx_EC_FP_ASIMD)
> + return true;
> +
> + if_sve (guest_has_sve && trap_class == ESR_ELx_EC_SVE)
> + return true;
Do we really need to check the guest has SVE before believing what the
hardware is telling us? According to the ARM ARM:
For ESR_ELx_EC_FP_ASIMD
Excludes exceptions resulting from CPACR_EL1 when the value of HCR_EL2.TGE is
1, or because SVE or Advanced SIMD and floating-point are not implemented. These
are reported with EC value 0b000000
But also for ESR_ELx_EC_SVE
Access to SVE functionality trapped as a result of CPACR_EL1.ZEN,
CPTR_EL2.ZEN, CPTR_EL2.TZ, or CPTR_EL3.EZ, that is not reported using EC
0b000000. This EC is defined only if SVE is implemented
Given I got confused maybe we need a comment for clarity?
/* Catch guests without SVE enabled running on SVE capable hardware */
> +
> + return false;
> +}
> +
> /*
> * Return true when we were able to fixup the guest exit and should return to
> * the guest, false when we should restore the host state and return to the
> @@ -387,6 +425,8 @@ static bool __hyp_text __hyp_switch_fpsimd(struct kvm_vcpu *vcpu)
> */
> static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> {
> + bool guest_has_sve;
> +
> if (ARM_EXCEPTION_CODE(*exit_code) != ARM_EXCEPTION_IRQ)
> vcpu->arch.fault.esr_el2 = read_sysreg_el2(esr);
>
> @@ -404,10 +444,11 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> * and restore the guest context lazily.
> * If FP/SIMD is not implemented, handle the trap and inject an
> * undefined instruction exception to the guest.
> + * Similarly for trapped SVE accesses.
> */
> - if (system_supports_fpsimd() &&
> - kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_FP_ASIMD)
> - return __hyp_switch_fpsimd(vcpu);
> + guest_has_sve = vcpu_has_sve(vcpu);
I'm not sure if it's worth fishing this out here given you are already
passing vcpu down the chain.
> + if (__hyp_trap_is_fpsimd(vcpu, guest_has_sve))
> + return __hyp_switch_fpsimd(vcpu, guest_has_sve);
>
> if (!__populate_fault_info(vcpu))
> return true;
Otherwise:
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2018-11-19 16:36 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-28 13:39 [RFC PATCH v2 00/23] KVM: arm64: Initial support for SVE guests Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 01/23] arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 02/23] KVM: arm64: Delete orphaned declaration for __fpsimd_enabled() Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 03/23] KVM: arm64: Refactor kvm_arm_num_regs() for easier maintenance Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 04/23] KVM: arm64: Add missing #include of <linux/bitmap.h> to kvm_host.h Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 05/23] KVM: arm: Add arch vcpu uninit hook Dave Martin
2018-11-02 8:05 ` Christoffer Dall
2018-11-15 16:40 ` Dave Martin
2018-11-20 10:56 ` Christoffer Dall
2018-09-28 13:39 ` [RFC PATCH v2 06/23] arm64/sve: Check SVE virtualisability Dave Martin
2018-11-15 15:39 ` Alex Bennée
2018-11-15 17:09 ` Dave Martin
2018-11-16 12:32 ` Alex Bennée
2018-11-16 15:09 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 07/23] arm64/sve: Enable SVE state tracking for non-task contexts Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 08/23] KVM: arm64: Add a vcpu flag to control SVE visibility for the guest Dave Martin
2018-11-15 15:44 ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 09/23] KVM: arm64: Propagate vcpu into read_id_reg() Dave Martin
2018-11-15 15:56 ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 10/23] KVM: arm64: Extend reset_unknown() to handle mixed RES0/UNKNOWN registers Dave Martin
2018-11-02 8:11 ` Christoffer Dall
2018-11-15 17:11 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 11/23] KVM: arm64: Support runtime sysreg filtering for KVM_GET_REG_LIST Dave Martin
2018-11-02 8:16 ` Christoffer Dall
2018-11-15 17:27 ` Dave Martin
2018-11-22 10:53 ` Christoffer Dall
2018-11-22 11:13 ` Peter Maydell
2018-11-22 12:34 ` Christoffer Dall
2018-11-22 12:59 ` Peter Maydell
2018-11-22 11:27 ` Alex Bennée
2018-11-22 12:32 ` Dave P Martin
2018-11-22 13:07 ` Christoffer Dall
2018-11-23 17:42 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 12/23] KVM: arm64/sve: System register context switch and access support Dave Martin
2018-11-15 16:37 ` Alex Bennée
2018-11-15 17:59 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 13/23] KVM: arm64/sve: Context switch the SVE registers Dave Martin
2018-11-19 16:36 ` Alex Bennée [this message]
2018-11-19 17:03 ` Dave Martin
2018-11-20 12:25 ` Alex Bennée
2018-11-20 14:17 ` Dave Martin
2018-11-20 15:30 ` Alex Bennée
2018-11-20 17:18 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 14/23] KVM: Allow 2048-bit register access via ioctl interface Dave Martin
2018-11-19 16:48 ` Alex Bennée
2018-11-19 17:07 ` Dave Martin
2018-11-20 11:20 ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 15/23] KVM: arm64/sve: Add SVE support to register access " Dave Martin
2018-11-21 15:20 ` Alex Bennée
2018-11-21 18:05 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 16/23] KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST Dave Martin
2018-11-21 16:09 ` Alex Bennée
2018-11-21 16:32 ` Dave Martin
2018-11-21 16:49 ` Alex Bennée
2018-11-21 17:46 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 17/23] arm64/sve: In-kernel vector length availability query interface Dave Martin
2018-11-21 16:16 ` Alex Bennée
2018-11-21 16:35 ` Dave Martin
2018-11-21 16:46 ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 18/23] KVM: arm64: Add arch vcpu ioctl hook Dave Martin
2018-11-02 8:30 ` Christoffer Dall
2018-09-28 13:39 ` [RFC PATCH v2 19/23] KVM: arm64/sve: Report and enable SVE API extensions for userspace Dave Martin
2018-11-22 15:23 ` Alex Bennée
2018-12-05 18:22 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 20/23] KVM: arm64: Add arch vm ioctl hook Dave Martin
2018-11-02 8:32 ` Christoffer Dall
2018-11-15 18:04 ` Dave Martin
2018-11-20 10:58 ` Christoffer Dall
2018-11-20 14:19 ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 21/23] KVM: arm64/sve: allow KVM_ARM_SVE_CONFIG_QUERY on vm fd Dave Martin
2018-11-22 15:29 ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 22/23] KVM: Documentation: Document arm64 core registers in detail Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 23/23] KVM: arm64/sve: Document KVM API extensions for SVE Dave Martin
2018-11-22 15:31 ` Alex Bennée
2018-12-05 17:59 ` Dave Martin
2018-11-22 15:34 ` [RFC PATCH v2 00/23] KVM: arm64: Initial support for SVE guests Alex Bennée
2018-12-04 15:50 ` Dave Martin
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=87sgzxhvny.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=Dave.Martin@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=cdall@kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=tokamoto@jp.fujitsu.com \
--cc=will.deacon@arm.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