From mboxrd@z Thu Jan  1 00:00:00 1970
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: [RFC PATCH 0/3] kvm: x86: speedups for APICv
Date: Fri, 30 Sep 2016 15:33:23 +0200
Message-ID: <20160930133323.GA18552@potion>
References: <1475011213-34225-1-git-send-email-pbonzini@redhat.com>
 <20160929195557.GE13257@potion>
 <1865155490.553427.1475185306049.JavaMail.zimbra@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        yang zhang wz <yang.zhang.wz@gmail.com>,
        feng wu <feng.wu@intel.com>, mst@redhat.com
To: Paolo Bonzini <pbonzini@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:47412 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932308AbcI3Nd1 (ORCPT <rfc822;kvm@vger.kernel.org>);
        Fri, 30 Sep 2016 09:33:27 -0400
Content-Disposition: inline
In-Reply-To: <1865155490.553427.1475185306049.JavaMail.zimbra@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

2016-09-29 17:41-0400, Paolo Bonzini:
>> 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?
> 
> I don't think there is a risk of inverting interrupt priority, because
> that race is always present.  But the overhead is probably too much, the
> cost of the one xchg in __apic_update_irr is probably half of the whole
> IRR update if the PI descriptor cacheline bounces.

Yep, I just ran the vmexit kvm-unit-benchmark -- the cpuid and hypercall
tests are ~1000 cycles slower if I send the notification self-IPI, which
should be far more than PIR->IRR + vmcs_write(RVI, fls(IRR)).