Xiantao, I understand that you wrote a lot of the code for the Per-cpu IDTs, including the IRQ migration code in __assign_irq_vector()? It looks to me like the general mechanism for moving looks like this: * Someone calls __assign_irq_vector(), which if it decides it needs to, will set cfg->move_in_progress * The next time that IRQ is triggered, do_IRQ calls desc->handler->ack(), which calls irq_complete_move(), which (if cfg->move_in_progress is set) calls send_cleanup_vector(). * send_cleanup_vector() sets move_cleanup_count, clears move_in_progress, and sends an IPI to the appropriate CPUs, which each do what they need to do and decrement move_cleanup_count. * When move_cleanup_count is zero, the migration is complete. Is my general understanding correct? The thing that seems a bit strange to me is that the "cleanup" which actually moves the vector is only triggered the next time the IRQ actually fires. If that doesn''t happen very often, then the irq can be in the "move_in_progress" state for an arbitrarily long time (perhaps forever), and all other modifications to it will fail. Is there a reason it has to wait for the IRQ to actually fire? Couldn''t we send the cleanup vectors right away? Or is there another way we could guarantee that irq_complete_move() happened in a timely manner? Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel