Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp2153117ybc; Wed, 20 Nov 2019 09:38:49 -0800 (PST) X-Google-Smtp-Source: APXvYqw8mxXASnTPYy9I45Ha5hDeFpXkjLP22rz6EeG5JrYtQUri+UpEypmpbLNF/5qxv8+kUQz9 X-Received: by 2002:adf:ef51:: with SMTP id c17mr5299238wrp.266.1574271528906; Wed, 20 Nov 2019 09:38:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574271528; cv=none; d=google.com; s=arc-20160816; b=xLq6I3KEyqr29RvvatxujF5nIpklVtsWK0VPUqxXY8vvwZXEEifzuhvWbUuHkMEDYW ySGq3NoxzRWr46FuflCr1oQPcD04wevyExrL40PCWUFLql/CEjn/r31BTo/wEe0yKJJ0 0RJ/ZaDTcn8Xxnm7RvoS8AAM6TLB8MEItw6XE6FcnY0XgMC96knpxVsK2W5FrOHh/JnA 5UT/DMISBBPD9siP9SmmYgM7mfrdEM33cwIFEKrFXJnjQ9q5hfq1CU73/I7RphpDhnAj tAlMTEWz+5FdkPfbX8FduMS4lD83uMcQgTf2hCg+o4UoqBxpukiycQkFVm+wKa79EKMU 7/DQ== 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=QGbTXvB6nn+ThHzQSSSkfj/Pwft6aTgIKEJ3nlZOjoQ=; b=RRkU3R9pe45+cWlL+rZxkyhInxzsdw2fmfr1lLkt6P0N0DWlmQ6oKGFGZGfueC3v3s 7jvffyu0bxLRDVACsg/7wGfvpTnxYKeB5BHNQhUj7N5tnbEcauiQMU8dFXvYbN/zyZ91 uWc/2VbN5Qqb1AmGET2BNwtmWxKMbXyN0Sg5XIWS6Erhb2KP2KJ4kLUETsfqA/JKFrPr 46GGEvvLq96bVW3nkoMGlnRCpem1ROb89wFg0x4BfIB5mpXjBJ4I7WRykNjpF6MvEua2 7puK+9fG/XFIRGfXlbyj4HKzlY1rDmXOLw1fVq057dOv7t12jD0U03m6H6fItx3CY5qM 9rSg== 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 p20si14820edq.121.2019.11.20.09.38.24; Wed, 20 Nov 2019 09:38:48 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732249AbfKTRCb (ORCPT + 99 others); Wed, 20 Nov 2019 12:02:31 -0500 Received: from mga09.intel.com ([134.134.136.24]:33587 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729936AbfKTRC3 (ORCPT ); Wed, 20 Nov 2019 12:02:29 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2019 09:02:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,222,1571727600"; d="scan'208";a="381430404" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.41]) by orsmga005.jf.intel.com with ESMTP; 20 Nov 2019 09:02:28 -0800 Date: Wed, 20 Nov 2019 09:02:28 -0800 From: Sean Christopherson To: Wanpeng Li Cc: Liran Alon , LKML , kvm , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel Subject: Re: [PATCH v2 1/2] KVM: VMX: FIXED+PHYSICAL mode single target IPI fastpath Message-ID: <20191120170228.GC32572@linux.intel.com> References: <1574145389-12149-1-git-send-email-wanpengli@tencent.com> <09CD3BD3-1F5E-48DA-82ED-58E3196DBD83@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Nov 20, 2019 at 11:49:36AM +0800, Wanpeng Li wrote: > On Tue, 19 Nov 2019 at 20:11, Liran Alon wrote: > > > + > > > +static void vmx_handle_exit_irqoff(struct kvm_vcpu *vcpu, u32 *exit_reason) > > > { > > > struct vcpu_vmx *vmx = to_vmx(vcpu); > > > > > > @@ -6231,6 +6263,8 @@ static void vmx_handle_exit_irqoff(struct kvm_vcpu *vcpu) > > > handle_external_interrupt_irqoff(vcpu); > > > else if (vmx->exit_reason == EXIT_REASON_EXCEPTION_NMI) > > > handle_exception_nmi_irqoff(vmx); > > > + else if (vmx->exit_reason == EXIT_REASON_MSR_WRITE) > > > + *exit_reason = handle_ipi_fastpath(vcpu); > > > > 1) This case requires a comment as the only reason it is called here is an > > optimisation. In contrast to the other cases which must be called before > > interrupts are enabled on the host. > > > > 2) I would rename handler to handle_accel_set_msr_irqoff(). To signal this > > handler runs with host interrupts disabled and to make it a general place > > for accelerating WRMSRs in case we would require more in the future. > > Yes, TSCDEADLINE/VMX PREEMPTION TIMER is in my todo list after this merged > upstream, handle all the comments in v3, thanks for making this nicer > further. :) Handling those is very different than what is being proposed here though. For this case, only the side effect of the WRMSR is being expedited, KVM still goes through the heavy VM-Exit handler path to handle emulating the WRMSR itself. To truly expedite things like TSCDEADLINE, the entire emulation of WRMSR would need be handled without going through the standard VM-Exit handler, which is a much more fundamental change to vcpu_enter_guest() and has different requirements. For example, keeping IRQs disabled is pointless for generic WRMSR emulation since the interrupt will fire as soon as KVM resumes the guest, whereas keeping IRQs disabled for processing ICR writes is a valid optimization since recognition of the IPI on the dest vCPU isn't dependent on KVM resuming the current vCPU. Rather than optimizing full emulation flows one at a time, i.e. exempting the ICR case, I wonder if we're better off figuring out a way to improve the performance of VM-Exit handling at a larger scale, e.g. avoid locking kvm->srcu unnecessarily, Andrea's retpolin changes, etc... Oh, a random thought, this fast path needs to be skipped if KVM is running L2, i.e. is_guest_mode(vcpu) is true.