WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: APIC errors resulting from too early set_timer()

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] Re: APIC errors resulting from too early set_timer()
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 29 Jun 2010 11:32:19 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 29 Jun 2010 03:33:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C29DEC302000078000088B2@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/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
Thread-index: AcsXcQAGms678uGzSI+5zxZvMer/kQABVnBJ
Thread-topic: APIC errors resulting from too early set_timer()
User-agent: Microsoft-Entourage/12.24.0.100205
On 29/06/2010 10:53, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> in c/s 17422 you moved the alloc_pdata scheduler callout into the
> CPU_UP_PREPARE notifier handler, but the credit scheduler uses
> set_timer() for a timer bound to the to be brought up CPU from
> sched_alloc_pdata(), with the resulting send_IPI_mask() targeting
> the not yet started CPU, thus (on my AMD systems at least)
> resulting in APIC send accept errors.
> 
> I see three possible fixes, neither really nice imo: Either a second
> callout (from CPU_ONLINE), or a credit scheduler specific notifier
> (handling CPU_ONLINE), or binding the timer initially to the current
> CPU, and migrate it to the target CPU as soon as that one's online.
> 
> Do you favor any one of these, or do you see any alternative?

The IPI is needless since the CPU will check for pending softirqs when it is
brought up, from its idle loop or before entering guest context for the
first time.

I suggest that we mask the given cpumap against cpu_online_map, and
smp_processor_id() while we're at it, in
arch/x86/smp.c:smp_send_event_check_mask(). If you agree that this makes
sense I will make the patch myself.

 Thanks,
 Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel