Messages in this thread | | | Date | Fri, 10 Apr 2009 17:56:06 +0400 | From | Cyrill Gorcunov <> | Subject | Re: [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
| |