From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758360AbZGGXtW (ORCPT ); Tue, 7 Jul 2009 19:49:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757166AbZGGXtP (ORCPT ); Tue, 7 Jul 2009 19:49:15 -0400 Received: from eddie.linux-mips.org ([78.24.191.182]:57676 "EHLO eddie.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756869AbZGGXtP (ORCPT ); Tue, 7 Jul 2009 19:49:15 -0400 Date: Wed, 8 Jul 2009 00:49:11 +0100 (BST) From: "Maciej W. Rozycki" To: "H. Peter Anvin" cc: Cyrill Gorcunov , Ingo Molnar , Thomas Gleixner , Yinghai Lu , LKML Subject: Re: [RFC -tip] x86,apic -- reduce disable_apic usage In-Reply-To: <4A50E323.6060109@zytor.com> Message-ID: References: <20090705162044.GC4791@lenovo> <4A50E323.6060109@zytor.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 5 Jul 2009, H. Peter Anvin wrote: > > How do you set cpu_has_apic for systems with discrete local APICs? The > > CPUID flag is not set in this case. > > > > Well, should it be? We do set flags when they're appropriate to us, and > if the semantics are such as that is inappropriate we can set a custom bit. Hmm, that might simplify things here and there and the less special cases in code -- and thus effort needed -- for the discrete APIC, the better. I think there is no reason why it couldn't be done -- all the places which need version-specific APIC features have to check the LVR register anyway. And the availability of the APICBASE MSR has to be validated separately too as it comes with P6+ only. The only place which could care I believe is code to set X86_FEATURE_11AP -- this should obviously be disabled for the discrete APIC as it is now, as the chip does not suffer from the erratum and the workaround is costly performance-wise. That piece of code would have to be checked -- I don't know what the order of setting of these bits would be and thus if one could affect the other. The dependency would better be well documented then too -- my observation is the knowledge about the APIC subsystem among people typically only covers a narrow subset of implementations. Maciej