From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?Q?Krcm=C3=A1r?= Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts Date: Mon, 18 Jan 2016 15:00:13 +0100 Message-ID: <20160118140012.GA14830@potion.brq.redhat.com> References: <1450229853-3886-1-git-send-email-feng.wu@intel.com> <1450229853-3886-2-git-send-email-feng.wu@intel.com> <20151223171932.GB7061@potion.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "pbonzini@redhat.com" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" To: "Wu, Feng" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44487 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754958AbcAROAQ (ORCPT ); Mon, 18 Jan 2016 09:00:16 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2016-01-18 05:19+0000, Wu, Feng: >> From: Radim Kr=C4=8Dm=C3=A1=C5=99 [mailto:rkrcmar@redhat.com] >> The drawback is that buggy software that included hardware disabled >> APICs to lowest priority destinations could stop working ... >=20 > Yes, if guest hardware disabled the APIC and we don't check "!dst[i]"= above, > interrupts could be still delivered to the hardware disabled APIC, ri= ght? The change allows hardware disabled APIC to be selected, but interrupts directed to it are (and should be) dropped on subsequent checks. >> Do you think it's too risky? >=20 > If you think the first loop have big bad impact on the performance, We don't want to do any unnecessary operations in the fast path. > I= think > your suggestion above is okay, since it is software's responsibility = to make > sure the LAPIC is hardware enabled before receiving the interrupt. I agree, thanks. > Ho= wever, > this will make the vector-hashing lowest-priority handling slightly d= ifferent > compare to round-robin, since RR checks "!dst[i]" before injecting th= e > interrupts. What is your opinion about it? Thanks a lot! I think that differing in forbidden (undefined) cases is not an issue. (We also differ on broadcast delivery, which goes through the slow path and currently omits disabled APICs; that's fine with me.)