From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755762AbcI2T4I (ORCPT ); Thu, 29 Sep 2016 15:56:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45318 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755315AbcI2T4D (ORCPT ); Thu, 29 Sep 2016 15:56:03 -0400 Date: Thu, 29 Sep 2016 21:55:57 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, yang.zhang.wz@gmail.com, feng.wu@intel.com, mst@redhat.com Subject: Re: [RFC PATCH 0/3] kvm: x86: speedups for APICv Message-ID: <20160929195557.GE13257@potion> References: <1475011213-34225-1-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1475011213-34225-1-git-send-email-pbonzini@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 29 Sep 2016 19:56:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2016-09-27 23:20+0200, Paolo Bonzini: > The difficult one is patch 2. I find the new code easier to follow than > the old one, but it doesn't mean it works. :) The aim is for APICv to > not use KVM_REQ_EVENT at all for interrupts, therefore turning APICv's > weakness (having to look at PIR on every vmentry) into a strength > (because checking PIR.ON is cheaper than processing KVM_REQ_EVENT). Makes sense. Another possible optimization: when delivering an IPI, don't write the vector to PIR, but directly to VIRR. If the guest is not in VMX non-root mode, then vm entry will take care of the injection; in the other case, we'll send POSTED_INTR_VECTOR. It seems that we don't even have to set PI.ON -- SDM doesn't say it is necessary to evaluate pending virtual interrupts after receiving the notification interrupt. If we have to set PI.ON, we can just skip the PIR->VIRR sync as long as the VM doesn't have an assigned device, because we know that PIR is empty. And a more far-fetched one: if we know that PI.ON is set before vm entry, we could just send POSTED_INTR_VECTOR self-IPI after masking interrupts and let APICv copy PIR to IRR and deliver interrupts. There are two possible drawbacks: Is the self-IPI overhead too big? Would APICv IRR evaluation at vm entry take precedence, so we'd have big interrupt priority inversion window?