From: [email protected] [mailto:[email protected]]
>> How about let apic_hangle_pending_vector take the irq too?
>We can't compute the vector by reading the hardware registers after
>we have acknowledged the irq.
>I hope that was the answer you were looking for I'm not quite certain
>what you mean by take.
I mean
+static void apic_handle_pending_vector(unsigned vector)
+{
+ unsigned irr;
+ int irq;
+
+ irq = __get_cpu_var(vector_irq)[vector];
+ if (irq >= 0)
+ return;
+
+ /* If the irq we are servicing has moved and is not pending
+ * free it's vector.
+ */
==>
+static void apic_handle_pending_vector(unsigned vector, unsigned irqx)
+{
+ unsigned irr;
+ int irq;
+
+ irq = __get_cpu_var(vector_irq)[vector];
+ if ( (-irq) != irqx)
+ return;
+
+
+ /* If the irq we are servicing has moved and is not pending
+ * free it's vector.
+ */
"Lu, Yinghai" <[email protected]> writes:
> From: [email protected] [mailto:[email protected]]
>>> How about let apic_hangle_pending_vector take the irq too?
>
>>We can't compute the vector by reading the hardware registers after
>>we have acknowledged the irq.
>
>>I hope that was the answer you were looking for I'm not quite certain
>>what you mean by take.
>
> I mean
I don't see the point. We would have to miscompute the vector that
we are servicing or improperly fill in vector_irq for that to be useful.
The only corner case I can see that might potentially happen is
"apic_in_service_vector() != irq_vector[irq]" and if that is the case
we don't want to migrate, because the precondition that we are in the
irq handler servicing the expected irq isn't true.
Of course someone would have to set IRQ_MOVE_PENDING pretty fast for
that case to hit, it's a tiny hole probably worth closing though.
Eric