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-ia64-devel

Re: [Xen-ia64-devel] [PATCH] pal_halt_light emulate for domU TAKE3

To: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [PATCH] pal_halt_light emulate for domU TAKE3
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Tue, 22 Aug 2006 12:43:45 +0900
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 21 Aug 2006 20:44:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200608211138.k7LBccHr023385@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200608211138.k7LBccHr023385@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
Hi Atsuhi.

On Mon, Aug 21, 2006 at 08:38:33PM +0900, Atsushi SAKAI wrote:

> 2)The VIRQ_ITC cycle is destroyed 
>   in case vcpu migration occurred when vcpu_pend_timer runs (called by 
> hlt_timer_fn)
>   
>   The VIRQ_ITC cycle is (simple writing)
>    ia64_get_itc reaches domain_itm at Xen.
>    send VIRQ_ITC to GuestOS
>    GuestOS handles and set  next itm by hypercall to Xen
>    Repeats.
>    
>   
>   Currently, the function order in vcpu_pend_timer is 
>   a)send VIRQ_ITC(vcpu_pend_timer)
>   b)then stamp the signal send information.(update domain_itm_last)
>   In this configuration, 
>   domain_itm_last update time and hypercall set itm(which comes from VIRQ_ITC)
>   is important. 
>   
>   This order is problematic in case vcpu_migration occurred as follows
>   (following event occures nearly 1-2 hour running 
>   by 2xDomU 3vcpu(total 6vcpu for domU) in 4pcpu Linux Kernel Compile test)
>   
>    vcpu_pend_timer@A is started.(GuestOS is not running at this moment) 
>    interrupts@B
>    vcpu_pend_timer@A is paused
>    Credit Scheduler steal vcpu from A to B
>    vcpu_pend_timer@B is started and ended
>    
>    ******The following process should be after vcpu_pend_timer*****
>    domain_itm is set by GuestOS hypercall. and domain_itm updated.
>    
>    vcpu_pend_timer@A is resumed. but domain_itm is already updated.
> 
>    
>   To avoid this, order should be exchanged b) a)
>   After this fixation, we are free from timing consideration of 
>   VIRQ_ITC cycle and domain_itm_last update time.
>   (domain_itm_last update should be before the hypercall set itm)

Could you elaborate more? I don't understand.
What phenomenan did you observed?

vcpu_pend_timer() is called with its parameter as current.
It means that test_bit(_VCPUF_running, vcpu->vcpu_flags) is 
always true becuase vcpu == current.
On the other hand, scheduler mustn't steal vcpu with _VCPUF_running set.
(see __csched_vcpu_is_stealable())
The vcpu stealing doesn't occur so that the above sequence
doesn't make sense (to me at least.)


Thanks.
-- 
yamahata

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