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


RE: [Xen-devel] spurious interrupts

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] spurious interrupts
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 12 Apr 2006 22:00:30 +0800
Delivery-date: Wed, 12 Apr 2006 07:01:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZeNkWGOCU2b7oNRSeUIsluRwKoiwAAYGoA
Thread-topic: [Xen-devel] spurious interrupts
>From: Jan Beulich
>Sent: 2006年4月12日 21:37
>Finally, sufficiently unrelated, I wonder whether
>xen_create_contiguous_region() (or its caller(s)) shouldn't special
>case order being zero, as it seems pointless to go through numerous
>hypercalls in that case.

The question is that corresponding gmfns is not necessarily contiguous.
Maybe instead of setting order to non-zero, we can change nr_extents
to >1 by allocating buffer to contain all gmfns to be released.

Another abstraction could be to incorporate set_phys_to_machine
into decrease/increase_reservation, and thus allow 
xen_create_contiguous_region to be used by auto_translated_mode if
we want that translated mode to work for backend like for xen/ia64...


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>