Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1390932ybn; Wed, 25 Sep 2019 17:38:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqyEHHZtHzZUlQQYaiLC3IqlNCnLjtFTVYbXURjzh+zgGz7rhVrgj5BmXtFlYGaDrNPbgB5I X-Received: by 2002:a50:f391:: with SMTP id g17mr779344edm.163.1569458287888; Wed, 25 Sep 2019 17:38:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569458287; cv=none; d=google.com; s=arc-20160816; b=f77ctCUJBzn6NV5SjR/qOKeMoL7fYW4iirGOeX9S1MrbSUrgdUBnAb6IE29gEAFAgy HB7wb8vtbiigBn2XDH5hFv+qHzhkk4GQLnJzwV7Evu5igSsno/1gIdjwEkZazDJ9wXzj z1U+G05WE5CNcLgNUeAhVUBlPgtfjLgpsrNCgyPOQ9JSUsEiz/x21jb7A0psIkS4Sg3C ywCZeaZDtD2GJiH7t5QlQH3+zWcHxOy/J/IYt2Y0dogRPrVMFLmrqyp40w/aU+z8O9nw 7XEvWufYft5Wwz1vrvrxXAaOhYRlpfS1rOyKY623npFf0xJYlVRXkkz3NzcZjH8uSBtf bY5Q== 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=RBSeK3OfIlfSHY8QMF23oXdXK+AAIPkjjDe/N5OmsGc=; b=E9u/xcPAzDkIyZvTqSrElbj6S3K9GQoc8c5yN8wOWaVb0pnhCsWpIczTlTpkzKfBH9 RIuIfo/SGRn+kVvDp6ts6h34gXbwVgisRnz2f/0SGq/dy1T1W4psZrnwo5LgUHrYl64M zeQ4MWkCaGcudo+0iyGaFpK7QYonW0H/6VlAePydv4JM9alaTHG1lG3GS5WiESW2Fttx dFXABZSZGUkGVOTmRBAF3gneEOby9+tKjQsVjU+BtTxJrDTgxojM3S6uuXuiiBDbDMbr Dq2YEde9V0Su7sh4/b+pyCPDQx8/gPukUM1hYTN9VtW2a7wLO7eoc9e5LpsazsMECQSD vNog== 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 b8si383083edc.231.2019.09.25.17.37.44; Wed, 25 Sep 2019 17:38:07 -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 S2503693AbfIXAq1 (ORCPT + 99 others); Mon, 23 Sep 2019 20:46:27 -0400 Received: from mga03.intel.com ([134.134.136.65]:37123 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390773AbfIXAq0 (ORCPT ); Mon, 23 Sep 2019 20:46:26 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Sep 2019 17:46:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,542,1559545200"; d="scan'208";a="195532991" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.41]) by FMSMGA003.fm.intel.com with ESMTP; 23 Sep 2019 17:46:25 -0700 Date: Mon, 23 Sep 2019 17:46:25 -0700 From: Sean Christopherson To: Paolo Bonzini Cc: Andrea Arcangeli , Vitaly Kuznetsov , "Dr. David Alan Gilbert" , Marcelo Tosatti , Peter Xu , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 15/17] KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers Message-ID: <20190924004625.GB13147@linux.intel.com> References: <20190920212509.2578-1-aarcange@redhat.com> <20190920212509.2578-16-aarcange@redhat.com> <87o8zb8ik1.fsf@vitty.brq.redhat.com> <7329012d-0b3b-ce86-f58d-3d2d5dc5a790@redhat.com> <20190923190514.GB19996@redhat.com> <20190923202349.GL18195@linux.intel.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 Tue, Sep 24, 2019 at 02:15:39AM +0200, Paolo Bonzini wrote: > On 23/09/19 22:23, Sean Christopherson wrote: > > > > +int nested_vmx_handle_vmx_instruction(struct kvm_vcpu *vcpu) > > +{ > > + switch (to_vmx(vcpu)->exit_reason) { > > + case EXIT_REASON_VMCLEAR: > > + return handle_vmclear(vcpu); > > + case EXIT_REASON_VMLAUNCH: > > + return handle_vmlaunch(vcpu); > > + case EXIT_REASON_VMPTRLD: > > + return handle_vmptrld(vcpu); > > + case EXIT_REASON_VMPTRST: > > + return handle_vmptrst(vcpu); > > + case EXIT_REASON_VMREAD: > > + return handle_vmread(vcpu); > > + case EXIT_REASON_VMRESUME: > > + return handle_vmresume(vcpu); > > + case EXIT_REASON_VMWRITE: > > + return handle_vmwrite(vcpu); > > + case EXIT_REASON_VMOFF: > > + return handle_vmoff(vcpu); > > + case EXIT_REASON_VMON: > > + return handle_vmon(vcpu); > > + case EXIT_REASON_INVEPT: > > + return handle_invept(vcpu); > > + case EXIT_REASON_INVVPID: > > + return handle_invvpid(vcpu); > > + case EXIT_REASON_VMFUNC: > > + return handle_vmfunc(vcpu); > > + } > > + > > Do you really need that? Why couldn't the handle_* functions simply be > exported from nested.c to vmx.c? Nope, just personal preference to keep the nested code as isolated as possible. We use a similar approach for vmx_{g,s}et_vmx_msr(). Though if we do want to go this route, it'd be better to simply move handle_vmx_instruction() to nested.c instead of bouncing through that and nested_vmx_handle_vmx_instruction().