Received: by 10.223.164.202 with SMTP id h10csp111078wrb; Mon, 13 Nov 2017 21:14:57 -0800 (PST) X-Google-Smtp-Source: AGs4zMaVDWpa/Nl6Aj2hhdV0EodT5qi3rVGNi+4yV33Eqei4WDxCA3CeVa405ZIjghk76dDg+zxH X-Received: by 10.99.127.85 with SMTP id p21mr11077406pgn.425.1510636496903; Mon, 13 Nov 2017 21:14:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510636496; cv=none; d=google.com; s=arc-20160816; b=p0VUkvICioW8hj9smlVhpHElLBvEQMhVKq7uK85+mB25IN9xRLYh4JYSokeVAtd2oH bvUeAap/TJQcHxTUptROuZVNccA84UsJdOGWWHPWTNt0wfLin8sri1WydfeJt+Jicwnb zNjP5uW1o6Ut2CWbWILzNge51BhMkRM2CAXS8Q50d+rgAKJ8RalKhdqlF8FxHZvxs6Tm rvfs3sW/HmkPBGqqXgdoKt8fN+PCVsDLu/gDUd2Xom+wtxcvutlfRi+LtZa3HCSwrtgJ nYoJk70LA3r0Y4a2HEQ3ztmro5Rmnb/PpXUYUSnGSNtkpJ9Z+Et50xznsGdU5wgke+3L Ekpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:message-id:subject:cc:to:from:date :arc-authentication-results; bh=7uqHpglj0oUKcgUfHvIGvOyn+lOPfAdB8iRtYIoL+LI=; b=0mRojpQ/W3zUBb2NxRfrD1mc23Z5Q32vCQWsQpi2SgkCQ0ovE3idUzf4+DfA5GEkTN cHdkXYJM5KWFn0WbGhYSH1OHUC+bOZUDcJORrzKQQ5OGscf5IXfWPmPynmRg1bSQlH6r KNzS0C5oC73HzNTHSnH/LDm9V3UFH/A4Oyx0IJPdZf6Kp278CAPuqt8mqq+ZQB04btzg 6y6tLb3Ai87yQcNoVQ4AGhaQwZN1Xsf3cfWU9eDkc2d0OMzoGi/QGlsBKEtfg6iWwa4h APIz4VxYfbWNfh80fKZmJMsIMddK8begXLF86YbyzytCQUdKM77DvwxF9nDl2/BjMO7u IMXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r3si8488294pli.600.2017.11.13.21.14.44; Mon, 13 Nov 2017 21:14:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753346AbdKNFMc (ORCPT + 89 others); Tue, 14 Nov 2017 00:12:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48622 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753177AbdKNFM1 (ORCPT ); Tue, 14 Nov 2017 00:12:27 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 387106A7CA; Tue, 14 Nov 2017 05:12:27 +0000 (UTC) Received: from annuminas.surriel.com (ovpn-126-55.rdu2.redhat.com [10.10.126.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3699F51676; Tue, 14 Nov 2017 05:12:26 +0000 (UTC) Date: Tue, 14 Nov 2017 00:12:23 -0500 From: Rik van Riel To: pbonzini@redhat.com Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, rkrcmar@redhat.com, borntraeger@de.ibm.com Subject: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run Message-ID: <20171114001223.441ea2ca@annuminas.surriel.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 14 Nov 2017 05:12:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently, every time a VCPU is scheduled out, the host kernel will first save the guest FPU/xstate context, then load the qemu userspace FPU context, only to then immediately save the qemu userspace FPU context back to memory. When scheduling in a VCPU, the same extraneous FPU loads and saves are done. This could be avoided by moving from a model where the guest FPU is loaded and stored with preemption disabled, to a model where the qemu userspace FPU is swapped out for the guest FPU context for the duration of the KVM_RUN ioctl. This is done under the VCPU mutex, which is also taken when other tasks inspect the VCPU FPU context, so the code should already be safe for this change. That should come as no surprise, given that s390 already has this optimization. No performance changes were detected in quick ping-pong tests on my 4 socket system, which is expected since an FPU+xstate load is on the order of 0.1us, while ping-ponging between CPUs is on the order of 20us, and somewhat noisy. There may be other tests where performance changes are noticeable. Signed-off-by: Rik van Riel Suggested-by: Christian Borntraeger --- arch/x86/include/asm/kvm_host.h | 13 +++++++++++++ arch/x86/kvm/x86.c | 29 ++++++++++++----------------- 2 files changed, 25 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index c73e493adf07..92e66685249e 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -536,7 +536,20 @@ struct kvm_vcpu_arch { struct kvm_mmu_memory_cache mmu_page_cache; struct kvm_mmu_memory_cache mmu_page_header_cache; + /* + * QEMU userspace and the guest each have their own FPU state. + * In vcpu_run, we switch between the user and guest FPU contexts. + * While running a VCPU, the VCPU thread will have the guest FPU + * context. + * + * Note that while the PKRU state lives inside the fpu registers, + * it is switched out separately at VMENTER and VMEXIT time. The + * "guest_fpu" state here contains the guest FPU context, with the + * host PRKU bits. + */ + struct fpu user_fpu; struct fpu guest_fpu; + u64 xcr0; u64 guest_supported_xcr0; u32 guest_xstate_size; diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 03869eb7fcd6..59912b20a830 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2917,7 +2917,6 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu) srcu_read_unlock(&vcpu->kvm->srcu, idx); pagefault_enable(); kvm_x86_ops->vcpu_put(vcpu); - kvm_put_guest_fpu(vcpu); vcpu->arch.last_host_tsc = rdtsc(); } @@ -6908,7 +6907,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) preempt_disable(); kvm_x86_ops->prepare_guest_switch(vcpu); - kvm_load_guest_fpu(vcpu); /* * Disable IRQs before setting IN_GUEST_MODE. Posted interrupt @@ -7095,6 +7093,8 @@ static int vcpu_run(struct kvm_vcpu *vcpu) vcpu->srcu_idx = srcu_read_lock(&kvm->srcu); + kvm_load_guest_fpu(vcpu); + for (;;) { if (kvm_vcpu_running(vcpu)) { r = vcpu_enter_guest(vcpu); @@ -7132,6 +7132,8 @@ static int vcpu_run(struct kvm_vcpu *vcpu) } } + kvm_put_guest_fpu(vcpu); + srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx); return r; @@ -7663,32 +7665,25 @@ static void fx_init(struct kvm_vcpu *vcpu) vcpu->arch.cr0 |= X86_CR0_ET; } +/* Swap (qemu) user FPU context for the guest FPU context. */ void kvm_load_guest_fpu(struct kvm_vcpu *vcpu) { - if (vcpu->guest_fpu_loaded) - return; - - /* - * Restore all possible states in the guest, - * and assume host would use all available bits. - * Guest xcr0 would be loaded later. - */ - vcpu->guest_fpu_loaded = 1; - __kernel_fpu_begin(); + preempt_disable(); + copy_fpregs_to_fpstate(&vcpu->arch.user_fpu); /* PKRU is separately restored in kvm_x86_ops->run. */ __copy_kernel_to_fpregs(&vcpu->arch.guest_fpu.state, ~XFEATURE_MASK_PKRU); + preempt_enable(); trace_kvm_fpu(1); } +/* When vcpu_run ends, restore user space FPU context. */ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu) { - if (!vcpu->guest_fpu_loaded) - return; - - vcpu->guest_fpu_loaded = 0; + preempt_disable(); copy_fpregs_to_fpstate(&vcpu->arch.guest_fpu); - __kernel_fpu_end(); + copy_kernel_to_fpregs(&vcpu->arch.user_fpu.state); + preempt_enable(); ++vcpu->stat.fpu_reload; trace_kvm_fpu(0); } From 1586053696324737171@xxx Wed Dec 06 16:44:34 +0000 2017 X-GM-THRID: 1581449088483558403 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread