lkml.org 
[lkml]   [2009]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC -tip] x86: do_IRQ - send APIC EOI for x86-32 on irq without handler v3
[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 :-)

|
| 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).

|
| > -#ifdef CONFIG_X86_64
| > - if (!disable_apic)
| > - ack_APIC_irq();
| > -#endif
| > -
| > + ack_APIC_irq_safe();
|
| Please keep the ack_APIC_irq() name - it is inherently safe to call
| it if we always give it a meaningful ->write method.
|
| Ingo
|

Ok, I think we eventually try to NOP'ify apic->write method
so this patch is plainly not needed (thanks for comments!).

Will back with new patch.

Cyrill


\
 
 \ /
  Last update: 2009-04-10 15:59    [W:0.060 / U:2.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site