From: Cyrill Gorcunov <gorcunov@gmail.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Yinghai Lu <yinghai@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC -tip] x86,apic -- reduce disable_apic usage
Date: Wed, 8 Jul 2009 18:44:52 +0400 [thread overview]
Message-ID: <20090708144452.GB5301@lenovo> (raw)
In-Reply-To: <alpine.LFD.2.00.0907080023470.13862@eddie.linux-mips.org>
[Maciej W. Rozycki - Wed, Jul 08, 2009 at 12:49:11AM +0100]
| 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
|
Thanks a lot for hints, Maciej! I've had an idea to set this bit
in verify_local_APIC (or something like that) since at this point
if discrete APIC happens -- we already complained in case of APIC
related BIOS problems. So that check-point should be safe. Anyway,
will recheck and put a big comment into patch.
-- Cyrill
prev parent reply other threads:[~2009-07-08 14:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-05 16:20 [RFC -tip] x86,apic -- reduce disable_apic usage Cyrill Gorcunov
2009-07-05 16:38 ` Maciej W. Rozycki
2009-07-05 16:59 ` Cyrill Gorcunov
2009-07-05 17:12 ` Cyrill Gorcunov
2009-07-05 17:17 ` Cyrill Gorcunov
2009-07-05 17:47 ` Maciej W. Rozycki
2009-07-05 18:12 ` Cyrill Gorcunov
2009-07-05 17:30 ` H. Peter Anvin
2009-07-05 19:02 ` Cyrill Gorcunov
2009-07-05 19:18 ` H. Peter Anvin
2009-07-05 19:46 ` Cyrill Gorcunov
2009-07-07 23:49 ` Maciej W. Rozycki
2009-07-08 14:44 ` Cyrill Gorcunov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090708144452.GB5301@lenovo \
--to=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox