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] Re: [PATCH] xen: always handle VIRQ_TIMER first.

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] xen: always handle VIRQ_TIMER first.
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Sat, 16 Oct 2010 07:48:37 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>
Delivery-date: Fri, 15 Oct 2010 23:49:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CB8C393.4080809@xxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <C8DE5C49.2627A%keir@xxxxxxx> <4CB8C393.4080809@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2010-10-15 at 22:11 +0100, Jeremy Fitzhardinge wrote:

> This situation doesn't seem like it is in any way Xen
> dependent, and AFAIK there's no general requirement that timer
> interrupts be handled first. 

It's not implicit somehow on native due to timer interrupt always being
IRQ0 or something like that?

> I'm guessing that this particular problem in the forward-port Xen
> kernel as a side-effect of its bespoke time handling code (including
> IDLE_NO_HZ) which is not doing something that the core time
> infrastructure would normally do.

You are right, it's very possible this is a forward-port Xen only

The patch is out there now so perhaps we should not worry about it and
revisit it if someone shows up with a plausible looking issue affecting

>   (I don't see why the forward-port
> kernels couldn't use the existing Xen time support in mainline rather
> than replacing it.) 

Agreed. Things like *front and the /dev/xen/* drivers would be good
first candidates for this sort of convergence too if someone were
interested. FWIW netback and blktap2 are already mostly converged in the
XCP tree which has made pushing patches back and forth much easier.


Xen-devel mailing list