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;
Subject: Re: [PATCH 12/14] KVM: retpolines: x86: eliminate retpoline from
 vmx.c exit handlers
To:     Andrea Arcangeli <aarcange@redhat.com>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org
Cc:     Vitaly Kuznetsov <vkuznets@redhat.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>
References: <20190928172323.14663-1-aarcange@redhat.com>
 <20190928172323.14663-13-aarcange@redhat.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
Openpgp: preference=signencrypt
Message-ID: <933ca564-973d-645e-fe9c-9afb64edba5b@redhat.com>
Date:   Tue, 15 Oct 2019 10:28:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190928172323.14663-13-aarcange@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 28/09/19 19:23, Andrea Arcangeli wrote:
> Reducing this list to only EXIT_REASON_MSR_WRITE,
> EXIT_REASON_PREEMPTION_TIMER, EXIT_REASON_EPT_MISCONFIG,
> EXIT_REASON_IO_INSTRUCTION increases the computation time of the
> hrtimer guest testcase on Haswell i5-4670T CPU @ 2.30GHz by 7% with
> the default spectre v2 mitigation enabled in the host and guest. On
> skylake as opposed there's no measurable difference with the short
> list. To put things in prospective on Haswell the same hrtimer
> workload (note: it never calls cpuid and it never attempts to trigger
> more vmexit on purpose) in guest takes 16.3% longer to compute on
> upstream KVM running in the host than with the KVM mono v1 patchset
> applied to the host kernel, while on skylake the same takes only 5.4%
> more time (both with the default mitigations enabled in guest and
> host).
> 
> It's also unclear why EXIT_REASON_IO_INSTRUCTION should be included.

If you're including EXIT_REASON_EPT_MISCONFIG (MMIO access) then you
should include EXIT_REASON_IO_INSTRUCTION too.  Depending on the devices
that are in the guest, the doorbell register might be MMIO or PIO.

> +		if (exit_reason == EXIT_REASON_MSR_WRITE)
> +			return kvm_emulate_wrmsr(vcpu);
> +		else if (exit_reason == EXIT_REASON_PREEMPTION_TIMER)
> +			return handle_preemption_timer(vcpu);
> +		else if (exit_reason == EXIT_REASON_PENDING_INTERRUPT)
> +			return handle_interrupt_window(vcpu);
> +		else if (exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
> +			return handle_external_interrupt(vcpu);
> +		else if (exit_reason == EXIT_REASON_HLT)
> +			return kvm_emulate_halt(vcpu);
> +		else if (exit_reason == EXIT_REASON_PAUSE_INSTRUCTION)
> +			return handle_pause(vcpu);
> +		else if (exit_reason == EXIT_REASON_MSR_READ)
> +			return kvm_emulate_rdmsr(vcpu);
> +		else if (exit_reason == EXIT_REASON_CPUID)
> +			return kvm_emulate_cpuid(vcpu);
> +		else if (exit_reason == EXIT_REASON_EPT_MISCONFIG)
> +			return handle_ept_misconfig(vcpu);

So, the difference between my suggested list (which I admit is just
based on conjecture, not benchmarking) is that you add
EXIT_REASON_PAUSE_INSTRUCTION, EXIT_REASON_PENDING_INTERRUPT,
EXIT_REASON_EXTERNAL_INTERRUPT, EXIT_REASON_HLT, EXIT_REASON_MSR_READ,
EXIT_REASON_CPUID.

Which of these make a difference for the hrtimer testcase?  It's of
course totally fine to use benchmarks to prove that my intuition was
bad---but you must also use them to show why your intuition is right. :)

Paolo