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] [PATCH] Pin vcpu for VMX domain

To: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Pin vcpu for VMX domain
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 8 Feb 2006 15:14:22 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 08 Feb 2006 15:19:13 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <FFEFE1749526634699CD3AC2EDB7627A010C6BFD@pdsmsx406>
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>
References: <FFEFE1749526634699CD3AC2EDB7627A010C6BFD@pdsmsx406>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 8 Feb 2006, at 12:58, Jiang, Yunhong wrote:

I'm not sure if it will has some corner case, and hope your
clarification for it.
considering following situation, assume the VMX switch from cpu 0->cpu1
1) on cpu0, the timer interrupt happened, so timer_softirq_action is
called, the pit_timer_fn is called, and in pit_timer_fn, it will try to
set the  pit timer again.
2) before pit_timer_fn set the pit timer on cpu0, the stop_timer is
called on cpu1 on vmx_reinstall_timers.
3) after stop_timer finished, the pit_timer_fn on cpu0 set the ac_timer
on cpu0.

on this situation, the stop_timer on cpu1 will has no effect. And then
the init_timer may cause error situation.

In fact, I think the old patch itself is not safe on this situation,
since the stop_timer is called on IPI interrupt , which may run when the
pit_timer_fn is running.

Good point. I'll have to add a migrate_timer() function I think, that does the migration atomically.
That'll save you the hassle of stop/init/reactivate as well.

 -- Keir

Xen-devel mailing list