Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp830959ybh; Tue, 10 Mar 2020 09:03:28 -0700 (PDT) X-Google-Smtp-Source: ADFU+vv49iD2QiHDvhv1t8hwWZsDuSvWsnO2u4wNiKMO0YvhHGlGwloovTokNNFpSp2kvOOcViKC X-Received: by 2002:a9d:6648:: with SMTP id q8mr17815395otm.105.1583856207842; Tue, 10 Mar 2020 09:03:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583856207; cv=none; d=google.com; s=arc-20160816; b=vquBHTup0ZWZ/hscy00ZqgyCEpazTZvKk6DWeC2SEwbxq1RHo1RR3bUwuDaAjB7Edf IG/vkl1gN7DAzEecooxyIGyrXEhb8Q2qMdE+O/elshpE1KkBSxh/Y3HzE0W660iyyk0w hbeJ0p1pzi4T8cyugD61AtSEEsqMcvrLP0qX1gjkyvYNtlrvlnf6Zsy7Bi56x9mNVtdL quaiqWaRKOlYsCDx8zcNctMi3ISeemZmPzNEhS9whqLxpGnvB3Hi59kzWvxnPCaRwYCl jDqYuJ766qfT2ERoJAe0zEwdsSvWOAjDGsB5X8gPxiKxGVImTx8zlEebYMxiFZKzfetV ZdNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=2zTqxUus+lYz1svLpjqzwxjC1U8YY8pV5CwIvCxPoC4=; b=f84q3W+bGynNDAojICgEtFzUxkuC8+0bERa1eRKyLBNBvIAOXLP7fgRyYQg8OtFyMV jaova4oBoQZjZ5vu0Np7Wjzsw3CSQGk2TDbIpBYzeaSmaYts/PNJnOQeQSTzIrvYGgU3 wSLo5vY39bbeffMg1jEznXgB11Om2Q1cIxN3pnmdAPFXfgW/1VeZQHFSLLEzmWzS45HR rlEVGKuJPx7FbKzPwzP+w7zxV5AZBWAidQODvZXBHSryTsDI0GTLr0XtPTb8XWwJU3kG 7ZdUifIx1boHLXgEmGtkXTW6oRlxKZthR9I0LOTFFhrDbg9S9plqJI52//2F7Ixu+ZWI glfQ== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a25si5654411oia.84.2020.03.10.09.02.56; Tue, 10 Mar 2020 09:03:27 -0700 (PDT) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726867AbgCJQBb (ORCPT + 99 others); Tue, 10 Mar 2020 12:01:31 -0400 Received: from mga14.intel.com ([192.55.52.115]:31254 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726445AbgCJQBb (ORCPT ); Tue, 10 Mar 2020 12:01:31 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2020 09:01:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,537,1574150400"; d="scan'208";a="353652216" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by fmsmga001.fm.intel.com with ESMTP; 10 Mar 2020 09:01:30 -0700 Date: Tue, 10 Mar 2020 09:01:29 -0700 From: Sean Christopherson To: Wanpeng Li Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel Subject: Re: [PATCH] KVM: X86: Don't load/put guest FPU context for sleeping AP Message-ID: <20200310160129.GA9305@linux.intel.com> References: <1583823679-17648-1-git-send-email-wanpengli@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1583823679-17648-1-git-send-email-wanpengli@tencent.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 10, 2020 at 03:01:19PM +0800, Wanpeng Li wrote: > From: Wanpeng Li > > kvm_load_guest_fpu() and kvm_put_guest_fpu() each consume more than 14us > observed by ftrace, the qemu userspace FPU is swapped out for the guest > FPU context for the duration of the KVM_RUN ioctl even if sleeping AP, > we shouldn't load/put guest FPU context for this case especially for > serverless scenario which sensitives to boot time. > > Signed-off-by: Wanpeng Li > --- > arch/x86/kvm/x86.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 5de2006..080ffa4 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -8680,7 +8680,6 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) > > vcpu_load(vcpu); > kvm_sigset_activate(vcpu); > - kvm_load_guest_fpu(vcpu); > > if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_UNINITIALIZED)) { > if (kvm_run->immediate_exit) { > @@ -8718,12 +8717,14 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) > } > } > > + kvm_load_guest_fpu(vcpu); Ugh, so this isn't safe on MPX capable CPUs, kvm_apic_accept_events() can trigger kvm_vcpu_reset() with @init_event=true and try to unload guest_fpu. We could hack around that issue, but it'd be ugly, and I'm also concerned that calling vmx_vcpu_reset() without guest_fpu loaded will be problematic in the future with all the things that are getting managed by XSAVE. > + > if (unlikely(vcpu->arch.complete_userspace_io)) { > int (*cui)(struct kvm_vcpu *) = vcpu->arch.complete_userspace_io; > vcpu->arch.complete_userspace_io = NULL; > r = cui(vcpu); > if (r <= 0) > - goto out; > + goto out_fpu; > } else > WARN_ON(vcpu->arch.pio.count || vcpu->mmio_needed); > > @@ -8732,8 +8733,9 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) > else > r = vcpu_run(vcpu); > > -out: > +out_fpu: > kvm_put_guest_fpu(vcpu); > +out: > if (vcpu->run->kvm_valid_regs) > store_regs(vcpu); > post_kvm_run_save(vcpu); > -- > 2.7.4 >