|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Xen IRQ migration
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- [Xen-devel] Xen IRQ migration,
George Dunlap <=
|
|
|
|
|