[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU
- To: "Atsushi SAKAI" <sakaia@xxxxxxxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
- From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
- Date: Wed, 5 Jul 2006 21:12:07 +0800
- Delivery-date: Wed, 05 Jul 2006 06:12:31 -0700
- List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
- Thread-index: Acaf5embiu6A0qkBTwiSWiHizJjpDwAS8hBg
- Thread-topic: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU
>From: Atsushi SAKAI
>Sent: 2006年7月5日 11:47
>This patch emulates Guest PAL_HALT_LIGHT on domU by using
>do_block and timer.
>It also adds the function of the timer event sending to domU at the vcpu
>Signed-off-by: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
>About the timer event sending to domU
>The function "xen_timer_interrupt" on ParaVM/IA64 only sends
>the timer signal to current vcpu.
>When the idle domain is running, no domUx receives timer signal.
>If some domain cannot receive the timer signal during 10 secs,
>a message "BUG: soft lockup detected appeared" comes from domUx.
>To avoid this, I add a timer check routine at the vcpu woke up.
Good catch, but... why do you need to choose minimal value from
(s - now) and (d - now)? Vcpu_get_next_time only serves for target vcpu
dedicatedly, and thus you only need to set an expiration value matching
what guest wants - (vITM - vITC). This is not like vcpu_set_next_time
which manipulates real mITM and needs to ensure other soft timer
BTW, there's no need for vcpu_set_next_timer in hlt_timer_fn, since
timer dispatcher will update mITM at end of scan loop and target vcpu
hasn't update a new vITM value yet at that point.
Xen-ia64-devel mailing list