From: Dave Martin <Dave.Martin@arm.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org,
Christoffer Dall <cdall@kernel.org>
Subject: Re: [PATCH v7 08/16] KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
Date: Wed, 9 May 2018 18:00:25 +0100 [thread overview]
Message-ID: <20180509170024.GR7753@e103592.cambridge.arm.com> (raw)
In-Reply-To: <b53227b8-8532-a395-184d-dc2b3654f607@arm.com>
On Wed, May 09, 2018 at 05:54:25PM +0100, Marc Zyngier wrote:
> On 09/05/18 17:12, Dave Martin wrote:
> > This patch refactors KVM to align the host and guest FPSIMD
> > save/restore logic with each other for arm64. This reduces the
> > number of redundant save/restore operations that must occur, and
> > reduces the common-case IRQ blackout time during guest exit storms
> > by saving the host state lazily and optimising away the need to
> > restore the host state before returning to the run loop.
> >
> > Four hooks are defined in order to enable this:
> >
> > * kvm_arch_vcpu_run_map_fp():
> > Called on PID change to map necessary bits of current to Hyp.
> >
> > * kvm_arch_vcpu_load_fp():
> > Set up FP/SIMD for entering the KVM run loop (parse as
> > "vcpu_load fp").
> >
> > * kvm_arch_vcpu_ctxsync_fp():
> > Get FP/SIMD into a safe state for re-enabling interrupts after a
> > guest exit back to the run loop.
> >
> > For arm64 specifically, this involves updating the host kernel's
> > FPSIMD context tracking metadata so that kernel-mode NEON use
> > will cause the vcpu's FPSIMD state to be saved back correctly
> > into the vcpu struct. This must be done before re-enabling
> > interrupts because kernel-mode NEON may be used by softirqs.
> >
> > * kvm_arch_vcpu_put_fp():
> > Save guest FP/SIMD state back to memory and dissociate from the
> > CPU ("vcpu_put fp").
> >
> > Also, the arm64 FPSIMD context switch code is updated to enable it
> > to save back FPSIMD state for a vcpu, not just current. A few
> > helpers drive this:
> >
> > * fpsimd_bind_state_to_cpu(struct user_fpsimd_state *fp):
> > mark this CPU as having context fp (which may belong to a vcpu)
> > currently loaded in its registers. This is the non-task
> > equivalent of the static function fpsimd_bind_to_cpu() in
> > fpsimd.c.
> >
> > * task_fpsimd_save():
> > exported to allow KVM to save the guest's FPSIMD state back to
> > memory on exit from the run loop.
> >
> > * fpsimd_flush_state():
> > invalidate any context's FPSIMD state that is currently loaded.
> > Used to disassociate the vcpu from the CPU regs on run loop exit.
> >
> > These changes allow the run loop to enable interrupts (and thus
> > softirqs that may use kernel-mode NEON) without having to save the
> > guest's FPSIMD state eagerly.
> >
> > Some new vcpu_arch fields are added to make all this work. Because
> > host FPSIMD state can now be saved back directly into current's
> > thread_struct as appropriate, host_cpu_context is no longer used
> > for preserving the FPSIMD state. However, it is still needed for
> > preserving other things such as the host's system registers. To
> > avoid ABI churn, the redundant storage space in host_cpu_context is
> > not removed for now.
> >
> > arch/arm is not addressed by this patch and continues to use its
> > current save/restore logic. It could provide implementations of
> > the helpers later if desired.
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> >
> > ---
> >
> > Dropped Reviewed-bys due to non-trivial changes.
> >
> > Changes since v6:
> >
> > * Don't define kvm_arch_vcpu_run_pid_change() unless CONFIG_KVM=y.
> >
> > <asm/kvm_host.h> may be used for its declarations even with
> > CONFIG_KVM=n (e.g., in asm-offsets.c).
> >
> > This patch avoids conflicts with the core headers in this config.
> >
> > * Rebind current's FP state to the cpu in vcpu_put() if it is
> > still loaded, to ensure that the SVE trapping setup for userspace is
> > properly restored.
> >
> > Requested by Marc Zyngier:
> >
> > * Add a comment to explain the purpose of update_fp_enabled().
> >
> > * Migrate vcpu_arch.flags definitions to kvm_host.h.
> >
> > * Eliminate magic NULL semantics for vcpu_arch.host_fpsimd_state so
> > that we can just assign this pointer once in the pid_change hook.
> >
> > A new flag KVM_ARM64_FP_HOST flag is added to capture the former
> > semantics of vcpu->arch.host_fpsimd_state != NULL.
> Thanks for the additional rework, that looks much better now.
>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Cool, thanks for wrapping your head around it.
Cheers
---Dave
next prev parent reply other threads:[~2018-05-09 17:00 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-09 16:12 [PATCH v7 00/16] KVM: arm64: Optimise FPSIMD context switching Dave Martin
2018-05-09 16:12 ` [PATCH v7 01/16] thread_info: Add update_thread_flag() helpers Dave Martin
2018-05-10 16:15 ` Catalin Marinas
2018-05-09 16:12 ` [PATCH v7 02/16] arm64: Use update{,_tsk}_thread_flag() Dave Martin
2018-05-09 16:17 ` Will Deacon
2018-05-09 16:27 ` Dave Martin
2018-05-09 16:55 ` Marc Zyngier
2018-05-09 17:08 ` Dave Martin
2018-05-10 16:16 ` Catalin Marinas
2018-05-09 16:12 ` [PATCH v7 03/16] KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change Dave Martin
2018-05-09 16:12 ` [PATCH v7 04/16] KVM: arm64: Convert lazy FPSIMD context switch trap to C Dave Martin
2018-05-09 16:12 ` [PATCH v7 05/16] arm64: fpsimd: Generalise context saving for non-task contexts Dave Martin
2018-05-10 16:17 ` Catalin Marinas
2018-05-09 16:12 ` [PATCH v7 06/16] arm64/sve: Refactor user SVE trap maintenance for external use Dave Martin
2018-05-09 16:36 ` Marc Zyngier
2018-05-09 16:41 ` Dave Martin
2018-05-09 16:47 ` Marc Zyngier
2018-05-10 16:41 ` Catalin Marinas
2018-05-09 16:12 ` [PATCH v7 07/16] KVM: arm64: Repurpose vcpu_arch.debug_flags for general-purpose flags Dave Martin
2018-05-15 10:55 ` Christoffer Dall
2018-05-09 16:12 ` [PATCH v7 08/16] KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing Dave Martin
2018-05-09 16:54 ` Marc Zyngier
2018-05-09 17:00 ` Dave Martin [this message]
2018-05-10 16:44 ` Catalin Marinas
2018-05-15 10:55 ` Christoffer Dall
2018-05-15 12:48 ` Dave Martin
2018-05-09 16:12 ` [PATCH v7 09/16] arm64/sve: Move read_zcr_features() out of cpufeature.h Dave Martin
2018-05-09 16:12 ` [PATCH v7 10/16] arm64/sve: Switch sve_pffr() argument from task to thread Dave Martin
2018-05-09 16:13 ` [PATCH v7 11/16] arm64/sve: Move sve_pffr() to fpsimd.h and make inline Dave Martin
2018-05-09 16:13 ` [PATCH v7 12/16] KVM: arm64: Save host SVE context as appropriate Dave Martin
2018-05-10 16:52 ` Catalin Marinas
2018-05-09 16:13 ` [PATCH v7 13/16] KVM: arm64: Remove eager host SVE state saving Dave Martin
2018-05-10 16:53 ` Catalin Marinas
2018-05-09 16:13 ` [PATCH v7 14/16] KVM: arm64: Remove redundant *exit_code changes in fpsimd_guest_exit() Dave Martin
2018-05-15 10:46 ` Christoffer Dall
2018-05-09 16:13 ` [PATCH v7 15/16] KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit() Dave Martin
2018-05-09 16:13 ` [PATCH v7 16/16] KVM: arm64: Invoke FPSIMD context switch trap from C Dave Martin
2018-05-15 10:57 ` Christoffer Dall
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=20180509170024.GR7753@e103592.cambridge.arm.com \
--to=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 \
/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