Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752638AbbLVG7m (ORCPT ); Tue, 22 Dec 2015 01:59:42 -0500 Received: from mga02.intel.com ([134.134.136.20]:30246 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750985AbbLVG7l convert rfc822-to-8bit (ORCPT ); Tue, 22 Dec 2015 01:59:41 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,463,1444719600"; d="scan'208";a="867054737" From: "Wu, Feng" To: Yang Zhang , "pbonzini@redhat.com" , "rkrcmar@redhat.com" CC: "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Jiang Liu (jiang.liu@linux.intel.com)" , "Wu, Feng" Subject: RE: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts Thread-Topic: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest-priority interrupts Thread-Index: AQHRO5FzVNvWlqsXtkO3uwvyjy20qJ7UrBtA//9/AQCAAIb+oIABWmEAgACIKwA= Date: Tue, 22 Dec 2015 06:59:25 +0000 Message-ID: References: <1450229853-3886-1-git-send-email-feng.wu@intel.com> <1450229853-3886-2-git-send-email-feng.wu@intel.com> <567759F2.5080809@gmail.com> <56775E9A.5030108@gmail.com> <5678F268.5070801@gmail.com> In-Reply-To: <5678F268.5070801@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3364 Lines: 92 > -----Original Message----- > From: Yang Zhang [mailto:yang.zhang.wz@gmail.com] > Sent: Tuesday, December 22, 2015 2:49 PM > To: Wu, Feng ; pbonzini@redhat.com; > rkrcmar@redhat.com > Cc: kvm@vger.kernel.org; linux-kernel@vger.kernel.org; Jiang Liu > (jiang.liu@linux.intel.com) > Subject: Re: [PATCH v2 1/2] KVM: x86: Use vector-hashing to deliver lowest- > priority interrupts > > >>>> > >>>> On 2015/12/16 9:37, Feng Wu wrote: > >>>>> Use vector-hashing to deliver lowest-priority interrupts, As an > >>>>> example, modern Intel CPUs in server platform use this method to > >>>>> handle lowest-priority interrupts. > >>>>> > >>>>> Signed-off-by: Feng Wu > >>>>> --- > >>>>> arch/x86/kvm/irq_comm.c | 27 ++++++++++++++++++----- > >>>>> arch/x86/kvm/lapic.c | 57 > >>>> ++++++++++++++++++++++++++++++++++++++++--------- > >>>>> arch/x86/kvm/lapic.h | 2 ++ > >>>>> arch/x86/kvm/x86.c | 9 ++++++++ > >>>>> arch/x86/kvm/x86.h | 1 + > >>>>> 5 files changed, 81 insertions(+), 15 deletions(-) > >>>>> > >>>>> bool kvm_irq_delivery_to_apic_fast(struct kvm *kvm, struct kvm_lapic > >> *src, > >>>>> struct kvm_lapic_irq *irq, int *r, unsigned long > *dest_map) > >>>>> { > >>>>> @@ -731,17 +747,38 @@ bool kvm_irq_delivery_to_apic_fast(struct kvm > >>>> *kvm, struct kvm_lapic *src, > >>>>> dst = map->logical_map[cid]; > >>>>> > >>>>> if (kvm_lowest_prio_delivery(irq)) { > >>>>> - int l = -1; > >>>>> - for_each_set_bit(i, &bitmap, 16) { > >>>>> - if (!dst[i]) > >>>>> - continue; > >>>>> - if (l < 0) > >>>>> - l = i; > >>>>> - else if (kvm_apic_compare_prio(dst[i]->vcpu, > >>>> dst[l]->vcpu) < 0) > >>>>> - l = i; > >>>>> + if (!kvm_vector_hashing_enabled()) { > >>>>> + int l = -1; > >>>>> + for_each_set_bit(i, &bitmap, 16) { > >>>>> + if (!dst[i]) > >>>>> + continue; > >>>>> + if (l < 0) > >>>>> + l = i; > >>>>> + else if (kvm_apic_compare_prio(dst[i]- > >>>>> vcpu, dst[l]->vcpu) < 0) > >>>>> + l = i; > >>>>> + } > >>>>> + bitmap = (l >= 0) ? 1 << l : 0; > >>>>> + } else { > >>>>> + int idx = 0; > >>>>> + unsigned int dest_vcpus = 0; > >>>>> + > >>>>> + for_each_set_bit(i, &bitmap, 16) { > >>>>> + if (!dst[i] > >>>> && !kvm_lapic_enabled(dst[i]->vcpu)) { > >>>> > >>>> It should be or(||) not and (&&). > >>> > >>> Oh, you are right! My negligence! Thanks for pointing this out, Yang! > >> > >> btw, i think the kvm_lapic_enabled check is wrong here? Why need it here? > > > > If the lapic is not enabled, I think we cannot recognize it as a candidate, can > we? > > Maybe Radim can confirm this, Radim, what is your option? > > Lapic can be disable by hw or sw. Here we only need to check the hw is > enough which is already covered while injecting the interrupt into > guest. I remember we(Glab, Macelo and me) have discussed it several ago, > but i cannot find the mail thread. But if the lapic is disabled by software, we cannot still inject interrupts to it, can we? Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/