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] timer interrupts, virqs, irq balance questions

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] timer interrupts, virqs, irq balance questions
From: Ryan Harper <ryanh@xxxxxxxxxx>
Date: Tue, 20 Sep 2005 10:06:42 -0500
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Delivery-date: Tue, 20 Sep 2005 15:04:47 +0000
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/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
User-agent: Mutt/1.5.6+20040907i
I've been looking into bug [1]#195 and I have a couple of questions on
how timer interrupts and virqs are handled.  Is it possible for dom0
linux to irq balance timer interrupts to different cpus?  That is, if
xen sends a VIRQ_TIMER to vcpu0, backed by cpu0, is it possible for that
interrupt to be handled by vcpu1, backed by cpu1 ?  

After putting in some debug code in to timer_interrupt in linux, I can
see that when we get a "Time went backwards" message, that
shadow->system_timestamp+offset is significantly behind the previous
value of processed_system_time, and that the previous value was set by
the OTHER vcpu.  


Timer ISR/0: Time went backwards:
delta=-44611438 cpu_delta=15388562 shadow=69081255546
off=254172405 processed=69380039389 cpu_processed=69320039389
last_modified=CPU1, prev_st=69291796314, prev_offset=92519230
 0: 69320039389
 1: 69380000000
Timer ISR/0: Time went backwards:
delta=-1374402 cpu_delta=528625598 shadow=69081255546
off=777409441 processed=69860039389 cpu_processed=69330039389
last_modified=CPU1, prev_st=69291796314, prev_offset=571453258
 0: 69330039389
 1: 69860000000
Timer ISR/1: Time went backwards:
delta=-150020322 cpu_delta=70019067 shadow=69291796314
off=798222753 processed=70240039389 cpu_processed=70020000000
last_modified=CPU0, prev_st=70243918726, prev_offset=14792
 0: 70240039389
 1: 70020000000

Of note to me was the other cpu was the last one to modified the
processed_system_time value.  I believe that 1) either the
system_timestamp from each cpus are wildly out of sync or 2) some how,
an interrupt destined for a particular vcpu, is actually handled on a
different cpu, which causes problems since the handler using
smp_processor_id() to index into the shared page for current values

Any thoughts or comments on this would be most helpful. 


1. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=195

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@xxxxxxxxxx

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

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