Re: [Xen-ia64-devel] [IPF-ia64] with Cset 10690, creating aVTImakexen0 hang

[Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>]

Hi, Anthony and Yamahata

Thank you for your comments. and sorry for late.
I know Anthony modification(stop_timer) fix the problem in empirically. 
But, I am investigating the reason.

The problem is two timer function exists after defining the hlt_timer_fn.
Two timer function confliction exists within the  vcpu_timer_expired => 
vcpu_pend_timer => DomU => vcpu_set_itm or hyper_set_itm
Because domain_itm keeps old value until vcpu_set_itm or hyper_set_itm is 
called.
For this reason, it has possibility that another VIRQ_ITC interrupt can call 
during this window.
To fix this problem, it should exclude VIRQ_ITC interrupt duing that time 
window.


and this problem is reproduced by using lmbench.(Thanks)


Thanks
Atsushi SAKAI



>Hi, Yamahata,
>
>If this domain depends on hlt_timer to wake it up,
>The scenario you described can appear,
>TIMER_SLOP can reduce this situation, but can't eliminate this situation.
>Maybe we need another mechanism to wake up VCPU, when this VCPU
>has been blocked for a certain time.
>
>Thanks,
>Anthony
>
>
>
>>From: Isaku Yamahata 
>>Hi SAKAI.
>>
>>The Anthony's modification is required.
>>Without the modification, all physical CPUs end up in the idle loop and
>>can't get out of it in spite of runnable vcpus existance because
>>of TIMER_SLOP. This issue isn't related to VT-i domain.
>>
>>Thanks.
>>
>>On Wed, Jul 12, 2006 at 10:30:47PM +0800, Xu, Anthony wrote:
>>> Hi, SAKAI
>>> Forget wrong analysis in early email,
>>>
>>> In the phase of EFI boot, there are many IO operations, so dom0 is woken up
>>by
>>> VTIdomain in most time, while hlt_timer is still registered, this may cause
>>more
>>> timer interrupts injected to dom0 than before.
>>>
>>> Hope following modification help
>>> #define TIMER_SLOP (50*1000) /* ns */
>>>       set_timer(&v->arch.hlt_timer,
>>vcpu_get_next_timer_ns(v)+TIMER_SLOP );
>>>       do_sched_op_compat(SCHEDOP_block, 0);
>>>       stop_timer(&v->arch.hlt_timer);
>>>
>>> Thanks,
>>> Anthony
>>>
>>>
>>> >-----Original Message-----
>>> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Xu,
>>Anthony
>>> >Sent: 2006?7?12? 21:13
>>> >To: Atsushi SAKAI; Alex Williamson; Zhang, Xiantao
>>> >Cc: Isaku Yamahata; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>> >Subject: RE: [Xen-ia64-devel] [IPF-ia64] with Cset 10690,creating
>>aVTImakexen0
>>> >hang
>>> >
>>> >>From: Atsushi SAKAI
>>> >>Sent: 2006?7?12? 19:05
>>> >>My primary motivation is correct display of xenmon.py and xentop in
>>BVT/CREDIT.
>>> >>(N.B. SEDF displayed as same as x86, but BVT/CREDIT are not)
>>> >>If only domU emulation is applied, it is a half way from my motivation.
>>> >>Is dom0 dispatch another home work?
>>> >>
>>> >
>>> >I suspect the slowness is not due to dom0 being scheduled out, but due to
>>> >hlt_timer
>>> >didn't work as expected.
>>> >           set_timer(&v->arch.hlt_timer, vcpu_get_next_timer_ns(v));
>>> >           do_sched_op_compat(SCHEDOP_block, 0);
>>> >There is a time window between set_timer and dom0 being scheduled out, and
>>psr.i
>>> >is 1. So if hlt_timer fires before do_sched_op_compat being called, dom0 
>>> >will
>>> >not be woken up by hlt_timer, and there is no timer interrupt for dom0 
>>> >until
>>> >domo
>>> >is woken up ,yes, dom0 can be woken up by other external interrupts, but 
>>> >not
>>> >by
>>> >timer interrupt. And since dom0 is involved in VTIdomain bootup, this may
>>lead
>>> >to slowness of VTIdomain bootup.
>>> >
>>> >Above is my analysis, there isn't any evidence.
>>> >
>>> >You can do experiment to check it.
>>> >Change above code sequence as following, this may reduce the impact of time
>>> >window.
>>> >
>>> >set_timer(&v->arch.hlt_timer,
>>> >cycle_to_ns(local_cpu_data->itm_delta)+NOW());
>>> >do_sched_op_compat(SCHEDOP_block, 0);
>>> >
>>> >_______________________________________________
>>> >Xen-ia64-devel mailing list
>>> >Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>> >http://lists.xensource.com/xen-ia64-devel
>>>
>>> _______________________________________________
>>> Xen-ia64-devel mailing list
>>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-ia64-devel
>>
>>--
>>yamahata
>







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