This patch series attempts to clarify the tracking of which set of floating point registers we save on systems supporting SVE, particularly with reference to KVM, and then uses the results of this clarification to improve the performance of simple syscalls where we return directly to userspace in cases where userspace is using SVE. At present we track which register state is active by using the TIF_SVE flag for the current task which also controls if userspace is able to use SVE, this is reasonably straightforward if limiting but for KVM it gets a bit hairy since we may have guest state loaded in registers. This results in KVM modifying TIF_SVE for the VMM task while the guest is running which doesn't entirely help make things easy to follow. To help make things clearer the series changes things so that in addition to TIF_SVE we explicitly track both the type of registers that are currently saved in the task struct and the type of registers that we should save when we do so. TIF_SVE then solely controls if userspace can use SVE without trapping, it has no function for KVM guests and we can remove the code for managing it from KVM. The refactoring to add the separate tracking is initially done by adding the new state together with checks that the state corresponds to expectations when we look at it before subsequent patches make use of the separated state, the goal being to both split out the more repetitive bits of tha change and make it easier to debug any problems that might arise. With the state tracked separately we then start to optimise the performance of syscalls when the process is using SVE. Currently every syscall disables SVE for userspace which means that we need to trap to EL1 again on the next SVE instruction, flush the SVE registers, and reenable SVE for EL0, creating overhead for tasks that mix SVE and syscalls. We build on the above refactoring to eliminate this overhead for simple syscalls which return directly to userspace by: - Keeping SVE enabled. - Not flushing the SVE state. The removal of flushing is within our currently documented ABI but is a change in our effective ABI so a sysctl is provided to revert to current behaviour in case of problems or to allow testing of userspace. If we don't want to do this I think we should tighten our ABI documentation, previously Catalin had indicated that he didn't want to tighten it. Mark Brown (7): KVM: arm64: Discard any SVE state when entering KVM guests arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE arm64/fpsimd: Have KVM explicitly say which FP registers to save arm64/fpsimd: Stop using TIF_SVE to manage register saving in KVM arm64/fpsimd: Load FP state based on recorded data type arm64/sve: Leave SVE enabled on syscall if we don't context switch arm64/sve: Don't zero non-FPSIMD register state on syscall by default arch/arm64/include/asm/fpsimd.h | 4 +- arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/include/asm/processor.h | 7 ++ arch/arm64/kernel/fpsimd.c | 136 +++++++++++++++++++++++------ arch/arm64/kernel/process.c | 2 + arch/arm64/kernel/ptrace.c | 6 +- arch/arm64/kernel/signal.c | 3 + arch/arm64/kernel/syscall.c | 53 ++++++++--- arch/arm64/kvm/fpsimd.c | 16 ++-- 9 files changed, 180 insertions(+), 48 deletions(-) base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56 -- 2.30.2 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
