This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Xen IRQ migration

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Xen IRQ migration
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Thu, 25 Nov 2010 18:45:40 +0000
Cc: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Delivery-date: Thu, 25 Nov 2010 10:46:33 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/0U+oW0nsRxC8M86QgcZi3juIyqFwi5cHIvIOg2k7xY=; b=d628T9HJQFTtGA/NjY7yFuvnn+4BPoNrY4bDzrZr229Zpy1wR3BQmgZzlg6LfWu6Kg eCyPcvg04J+eToiG2ZVYgicCkmm+of5vos5LZGRlbjdSfdW92pXCRmxiQN263asnITW7 i6Dy5pKfpKXcDM4hxbAB3VOQphPfyhnXFuOFQ=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=Zq2o1NGoQpXLAqmbPAVL/lFKUUSAUZPUUbKP17hVL/I1w4jTzlW3dtoxPbpiwJezK9 QJNLIdI8QrWJwONmBZnJU9hQuoyK8h42Ai55qX8FwrfO6cfBxWjKF3RpNlw1vok6DCvf Nd+nwc5NRRpohJylzVk7iHpy5FswEoNKQv5F8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Xen IRQ migration, George Dunlap <=