Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753442AbcLLQ3t (ORCPT ); Mon, 12 Dec 2016 11:29:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36966 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752100AbcLLQ3r (ORCPT ); Mon, 12 Dec 2016 11:29:47 -0500 Date: Mon, 12 Dec 2016 17:29:43 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Denis Plotnikov Cc: rkagan@virtuozzo.com, den@virtuozzo.com, pbonzini@redhat.com, svt-core@lists.sw.ru, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] KVM: x86: avoid redundant REQ_EVENT Message-ID: <20161212162943.GA2237@potion> References: <20161212140223.277077-1-dplotnikov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161212140223.277077-1-dplotnikov@virtuozzo.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 12 Dec 2016 16:29:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1894 Lines: 44 2016-12-12 17:02+0300, Denis Plotnikov: > When processing KVM_REQ_EVENT, apic_update_ppr is called which may set > KVM_REQ_EVENT again if the recalculated value of PPR becomes smaller > than the previous one. This results in cancelling the guest entry and > reiterating in vcpu_enter_guest. > > However this is unnecessary because at this point KVM_REQ_EVENT is > already being processed and there are no other changes in the lapic > that may require full-fledged state recalculation. > > This situation is often hit on systems with TPR shadow, where the > TPR can be updated by the guest without a vmexit, so that the first > apic_update_ppr to notice it is exactly the one called while > processing KVM_REQ_EVENT. > > To avoid it, introduce a parameter in apic_update_ppr allowing to > suppress setting of KVM_REQ_EVENT, and use it on the paths called from > KVM_REQ_EVENT processing. We also call: kvm_cpu_get_interrupt() in nested_vmx_vmexit() - that path is intended without KVM_REQ_EVENT kvm_cpu_has_interrupt() in vmx_check_nested_events(), - I think it does no harm kvm_cpu_has_interrupt() in kvm_vcpu_has_events() kvm_cpu_has_interrupt() in kvm_vcpu_ready_for_interrupt_injection() - both seem safe as we should not have an interrupt between TPR threshold and the new PPR value, so the KVM_REQ_EVENT was useless. I would prefer we made sure that only callers from KVM_REQ_EVENT used the function we are changing -- it is really easy to make a hard-to-find mistake in interrupt delivery. > This microoptimization gives 10% performance increase on a synthetic > test doing a lot of IPC in Windows using window messages. > > Reviewed-by: Roman Kagan > Signed-off-by: Denis Plotnikov > --- Still, there is a high possibility that this is going to work, Reviewed-by: Radim Krčmář