Andi Kleen <[EMAIL PROTECTED]> writes: >> Once the migration operation is complete we know we will receive >> no more interrupts on this vector so the irq pending state for >> this irq will no longer be updated. If the irq is not pending and >> we are in the intermediate state we immediately free the vector, >> otherwise in we free the vector in do_IRQ when the pending irq >> arrives. > > Ok for me, although the magic numbers are a little nasty.
You must be talking about (vector/32) *0x10. The 32 is the number of bits and 0x10 the gap between apic registers. I couldn't think of a better form. If someone can think of a better way it probably warrants a cleanup patch at some point. > What about i386? i386 does not handle this case but since it is still globally allocating all of it's vectors and never changes it's vectors during migration it is totally harmless when an irq comes in on a cpu other than the one we are expecting it on. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
