[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel][PATCH] FIX THIS ISSUE.RE: [Xen-ia64-devel] VTidomain problems


  • To: "Atsushi SAKAI" <sakaia@xxxxxxxxxxxxxx>, "Alex Williamson" <alex.williamson@xxxxxx>, "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
  • Date: Mon, 28 Aug 2006 15:36:19 +0800
  • Delivery-date: Mon, 28 Aug 2006 00:36:41 -0700
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcbKcDSN9FCkWiZhSDSjkoHqUAoB8AAAIUMQ
  • Thread-topic: [Xen-ia64-devel][PATCH] FIX THIS ISSUE.RE: [Xen-ia64-devel] VTidomain problems

Assume dom0(UP) and VTI-domain(UP) are running on a same LP,
1. dom0 sets itm, assume machine itm is set to this itm.
2. dom0 is scheduled out to other LP,
3. VTI-domain is scheduled in.
4. VTI-domain is blocked due to emulating hal_light.
5. idle_dom is schedule in.
6. machine timer interrupt happens, xen_timer_interrupt is called.

        if (!is_idle_domain(current->domain)&&!VMX_DOMAIN(current))
                if (vcpu_timer_expired(current)) {
                        vcpu_pend_timer(current);
                        // ensure another timer interrupt happens even if 
domain doesn't
                        vcpu_set_next_timer(current);
                }

        new_itm = local_cpu_data->itm_next;

        if (!VMX_DOMAIN(current) && !time_after(ia64_get_itc(), new_itm))
                return;
7. due to it is idle_domain,  vcpu_set_next_timer is not called, so machine itm 
is not set
8 assume new_itm is after ia64_get_itc, return,
9. There is no machine itm being set at this time, There is no timer interrupt 
   any more.
10. VTI-domain is only waiting for tiemr interrupt to fire guest timer, so 
There is no IPI send to this LP, 
11. idle_dom calls pal_halt_light and will not return.







>-----Original Message-----
>From: Atsushi SAKAI [mailto:sakaia@xxxxxxxxxxxxxx]
>Sent: 2006?8?28? 15:03
>To: Xu, Anthony; Alex Williamson; xen-ia64-devel
>Subject: Re: [Xen-ia64-devel][PATCH] FIX THIS ISSUE.RE: [Xen-ia64-devel]
>VTidomain problems
>
>Hi, Anthony
>
>Could you explain following cases?
>
>Anyway, thank you for your patch of pal_halt_light domU.
>
>Thanks,
>Atsushi SAKAI
>
>>In some scenarios, xen_timer_interrupt will not set machine itm,
>>this may make this LP not receive timer interrupt any more.
>>
>>Signed-off-by: Anthony Xu < anthony.xu@xxxxxxxxx >
>>
>>Thanks,
>>Anthony
>>
>>>-----Original Message-----
>>>From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>>[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Xu,
>Anthony
>>>Sent: 2006?8?28? 10:49
>>>To: Alex Williamson; xen-ia64-devel
>>>Subject: RE: [Xen-ia64-devel] VTi domain problems
>>>
>>>Alex
>>>
>>>I'm looking at this.
>>>
>>>Thanks,
>>>Anthony
>>>
>>>>-----Original Message-----
>>>>From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>>>[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Alex
>>>>Williamson
>>>>Sent: 2006?8?28? 10:46
>>>>To: xen-ia64-devel
>>>>Subject: [Xen-ia64-devel] VTi domain problems
>>>>
>>>>
>>>>   I merged with xen-unstable.hg again in preparation for a pull
>>>>request, but I'm seeing problems with VTi domains.  The domain is
>>>>getting stuck in the blocked state, and not accumulating CPU time.
>>>>Checking the vcpu state with xenctx, nothing seems to be happening.  The
>>>>register state consistently looks like the output below.  I've seen this
>>>>happen in a least 2 different places during the bootup of RHEL4U3 in my
>>>>VTi guest domain.  Is anyone else seeing this?  Thanks,
>>>>
>>>>    Alex
>>>>
>>>>iip:  e00000007e60b750
>>>>psr:  0088029792460856   b0:  e00000007e609200
>>>> r1:  a0000001009add90
>>>> r2:  0000000000000101   r3:  0000000000000103
>>>> r4:  0000000000000000   r5:  0000000000000000
>>>> r6:  0000000000000000   r7:  0000000000000000
>>>> r8:  0000000000000000   r9:  ffffffffffffb700
>>>> r10: 80000000ffff7000   r11: 0000000000000001
>>>> sp:  a0000001006dbd80   tp:  a0000001006d4000
>>>> r14: 800000000000000e   r15: 000000000000ffff
>>>> r16: a0000001006dbcf0   r17: a0000001006dbd60
>>>> r18: 0000000000000103   r19: 0000000000000104
>>>> r20: 00000001006d4000   r21: 0000000000000100
>>>> r22: 0000000000000102   r23: 0000000000000000
>>>> r24: 0000000000000000   r25: 0000000000000000
>>>> r26: 0000000000000000   r27: a0000001006d5148
>>>> r28: 000000000000001d   r29: 0000000000000000
>>>> r30: 0000000000000000   r31: 0000000000000000
>>>>
>>>>--
>>>>Alex Williamson                             HP Open Source & Linux Org.
>>>>
>>>>
>>>>_______________________________________________
>>>>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
>
>>_______________________________________________
>>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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.