Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754474AbbKYOMo (ORCPT ); Wed, 25 Nov 2015 09:12:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752145AbbKYOMm (ORCPT ); Wed, 25 Nov 2015 09:12:42 -0500 Date: Wed, 25 Nov 2015 15:12:39 +0100 From: Radim =?utf-8?Q?Krcm=C3=A1r?= 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 Message-ID: <20151125141238.GC13925@potion.brq.redhat.com> References: <1447037208-75615-1-git-send-email-feng.wu@intel.com> <20151116190314.GA12245@potion.brq.redhat.com> <20151124143154.GB13925@potion.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1688 Lines: 33 2015-11-25 03:21+0000, Wu, Feng: > From: Radim Krčmář [mailto:rkrcmar@redhat.com] >> 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! I think it's ok to pick any algorithm we like. It's unlikely that software would recognize and take advantage of the hardware algorithm without adding a special treatment for KVM. (I'd vote for the simple pick-first-APIC lowest priority algorithm ... I don't see much point in complicating lowest priority when it doesn't deliver to lowest priority CPU anyway.) I mainly wanted to know what real hardware really does, because there is a lot of alternatives that still fit into the Xeon documentation. -- 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/