From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
Yinghai Lu <yhlu.kernel@gmail.com>
Subject: Re: [RFC -tip] x86: do_IRQ - send APIC EOI for x86-32 on irq without handler v3
Date: Sat, 11 Apr 2009 00:29:42 +0400 [thread overview]
Message-ID: <20090410202941.GF8204@lenovo> (raw)
In-Reply-To: <20090410140023.GA29090@elte.hu>
[Ingo Molnar - Fri, Apr 10, 2009 at 04:00:23PM +0200]
|
| * Cyrill Gorcunov <gorcunov@gmail.com> wrote:
|
| > [Ingo Molnar - Fri, Apr 10, 2009 at 02:27:50PM +0200]
| > |
| > | * Cyrill Gorcunov <gorcunov@openvz.org> wrote:
| > |
| > | > Ingo, I've checked the sources and as far as I see
| > | > we could NOP'ify apic->write indeed but I have
| > | > an internal feeling that this will bring us more problem
| > | > in future (for example it could be the following scenario:
| > | > some screwed APIC would require cleaning of LVT's or
| > | > IRR after resume regardless if it was initialized
| > | > or not at all). Mostly I mean that the idea of making
| > | > apic->write NOP'ified is quite elegant indeed but
| > | > cut off the subset of apic operations (we need
| > | > apic->read anyway) somehow bothering me from inside :)
| > |
| > | it's as if assigned a special type of 'dummy apic' struct apic. It
| > | wont cause problems down the line: we use the new APIC driver
| > | infrastructure to abstract out quirks.
| >
| > Well, it's not that new actually :-)
|
| Yeah, i mean the new unified/modernized code in 2.6.30-to-be.
|
| > |
| > | one small detail:
| > |
| > | > +/* Ack APIC irq if it's enabled only */
| > | > +static inline void ack_APIC_irq_safe(void)
| > | > +{
| > | > +#ifdef CONFIG_X86_LOCAL_APIC
| > | > + if (cpu_has_apic)
| > | > + ack_APIC_irq();
| > | > +#endif
| > |
| > | we dont need the cpu_has_apic check there, do we? In the
| > | !cpu_has_apic the ->write method should be a dummy.
| >
| > Yes. In case you're talking about it'll not be needed
| > (we will find earlier whether cpu_has_apic or not).
|
| yeah.
|
| Ingo
|
Ingo,
I think you meant something like the patch below. It's
not finished yet -- I need to find out right place for
calling freshly introduced apic_disable_write_op.
Will continue tomorrow.
But even having it not completed yet I would like to
get some feedbackabout code structure in general.
Cyrill
---
arch/x86/include/asm/apic.h | 10 ++++++++++
arch/x86/kernel/apic/apic.c | 6 ++++++
arch/x86/kernel/irq.c | 10 ++--------
3 files changed, 18 insertions(+), 8 deletions(-)
Index: linux-2.6.git/arch/x86/include/asm/apic.h
=====================================================================
--- linux-2.6.git.orig/arch/x86/include/asm/apic.h
+++ linux-2.6.git/arch/x86/include/asm/apic.h
@@ -106,6 +106,7 @@ extern void native_apic_wait_icr_idle(vo
extern u32 native_safe_apic_wait_icr_idle(void);
extern void native_apic_icr_write(u32 low, u32 id);
extern u64 native_apic_icr_read(void);
+extern void native_apic_write_dummy(u32 reg, u32 v);
#define EIM_8BIT_APIC_ID 0
#define EIM_32BIT_APIC_ID 1
@@ -372,6 +373,15 @@ static inline void apic_write(u32 reg, u
apic->write(reg, val);
}
+/*
+ * right after this call apic->write doesn't do anything
+ * note that there is no restore operation it works one way
+ */
+static inline void apic_disable_write_op(void)
+{
+ apic->write = native_apic_write_dummy;
+}
+
static inline u64 apic_icr_read(void)
{
return apic->icr_read();
Index: linux-2.6.git/arch/x86/kernel/apic/apic.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/apic/apic.c
+++ linux-2.6.git/arch/x86/kernel/apic/apic.c
@@ -210,6 +210,12 @@ static int modern_apic(void)
return lapic_get_version() >= 0x14;
}
+/*
+ * bare function to substitute write operation
+ * and it's _that_ fast :)
+ */
+void native_apic_write_dummy(u32 reg, u32 v) { }
+
void native_apic_wait_icr_idle(void)
{
while (apic_read(APIC_ICR) & APIC_ICR_BUSY)
Index: linux-2.6.git/arch/x86/kernel/irq.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/irq.c
+++ linux-2.6.git/arch/x86/kernel/irq.c
@@ -27,7 +27,6 @@ void ack_bad_irq(unsigned int irq)
if (printk_ratelimit())
pr_err("unexpected IRQ trap at vector %02x\n", irq);
-#ifdef CONFIG_X86_LOCAL_APIC
/*
* Currently unexpected vectors happen only on SMP and APIC.
* We _must_ ack these because every local APIC has only N
@@ -37,9 +36,7 @@ void ack_bad_irq(unsigned int irq)
* completely.
* But only ack when the APIC is enabled -AK
*/
- if (cpu_has_apic)
- ack_APIC_irq();
-#endif
+ ack_APIC_irq();
}
#define irq_stats(x) (&per_cpu(irq_stat, x))
@@ -224,10 +221,7 @@ unsigned int __irq_entry do_IRQ(struct p
irq = __get_cpu_var(vector_irq)[vector];
if (!handle_irq(irq, regs)) {
-#ifdef CONFIG_X86_64
- if (!disable_apic)
- ack_APIC_irq();
-#endif
+ ack_APIC_irq();
if (printk_ratelimit())
pr_emerg("%s: %d.%d No irq handler for vector (irq %d)\n",
next prev parent reply other threads:[~2009-04-10 20:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 18:18 [RFC -tip] x86: do_IRQ - send APIC EOI for x86-32 on irq without handler v3 Cyrill Gorcunov
2009-04-10 12:27 ` Ingo Molnar
2009-04-10 13:56 ` Cyrill Gorcunov
2009-04-10 14:00 ` Ingo Molnar
2009-04-10 20:29 ` Cyrill Gorcunov [this message]
2009-04-12 14:06 ` Ingo Molnar
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=20090410202941.GF8204@lenovo \
--to=gorcunov@gmail.com \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=yhlu.kernel@gmail.com \
/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.