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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.