Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932472AbbKYDVv (ORCPT ); Tue, 24 Nov 2015 22:21:51 -0500 Received: from mga14.intel.com ([192.55.52.115]:54442 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755385AbbKYDVt convert rfc822-to-8bit (ORCPT ); Tue, 24 Nov 2015 22:21:49 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,341,1444719600"; d="scan'208";a="846543538" From: "Wu, Feng" To: =?iso-8859-2?Q?Radim_Krcm=E1r?= CC: "pbonzini@redhat.com" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Wu, Feng" Subject: RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts Thread-Topic: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts Thread-Index: AQHRIKFx7uN6i1xR7ke/FgyVZroC0p6qX1YggABjBoCAAVqyEA== Date: Wed, 25 Nov 2015 03:21:44 +0000 Message-ID: References: <1447037208-75615-1-git-send-email-feng.wu@intel.com> <20151116190314.GA12245@potion.brq.redhat.com> <20151124143154.GB13925@potion.brq.redhat.com> In-Reply-To: <20151124143154.GB13925@potion.brq.redhat.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="iso-8859-2" 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: 2360 Lines: 59 > -----Original Message----- > From: Radim Kr?m?? [mailto:rkrcmar@redhat.com] > Sent: Tuesday, November 24, 2015 10:32 PM > To: Wu, Feng > Cc: pbonzini@redhat.com; kvm@vger.kernel.org; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted- > interrupts > > 2015-11-24 01:26+0000, Wu, Feng: > > "I don't think we do any vector hashing on our client parts. This may be > why the customer is not able to detect this on Skylake client silicon. > > The vector hashing is micro-architectural and something we had done on > server parts. > > > > If you look at the haswell server CPU spec (https://www- > ssl.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon- > e5-v3-datasheet-vol-2.pdf) > > In section 4.1.2, you will see an IntControl register (this is a register > controlled/configured by BIOS) - see below. > > Thank you! > > > If you look at bits 6:4 in that register, you see the option we offer in > hardware for what kind of redirection is applied to lowest priority interrupts. > > There are three options: > > 1. Fixed priority > > 2. Redirect last > > 3. Hash Vector > > > > If picking vector hash, then bits 10:8 specifies the APIC-ID bits used for the > hashing." > > The hash function just interprets a subset of vector's bits as a number > and uses that as a starting offset in a search for an enabled APIC > within the destination set? > > For example: > The x2APIC destination is 0x00000055 (= first four even APICs in cluster > 0), the vector is 0b11100000, and bits 10:8 of IntControl are 000. > > 000 means that bits 7:4 of vector are selected, thus the vector hash is > 0b1110 = 14, so the round-robin effectively does 14 % 4 (because we only > have 4 destinations) and delivers to the 3rd possible APIC (= ID 6)? In my current implementation, I don't select a subset of vector's bits as the number, instead, I use the whole vector number. For software emulation p. o. v, do we really need to select a subset of the vector's bits as the base number? What is your opinion? Thanks a lot! Thank, 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/