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] fixed some bugs to make xen0 more stable

To: "Xu, Anthony" <anthony.xu@xxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Fri, 14 Oct 2005 13:50:29 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 14 Oct 2005 05:47:48 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXP2HRI83rf2/ODRBuc5moDrgGuwgAGusrwABuUQoAAB/9R4A==
Thread-topic: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable
After further thought, I have below concern.
If real PAL call is called, only when guest is executing PAL call, lazy PAL 
mapping is a good method. But HV may call PAL call itself. On vti-domain, HV 
will call PAL_PTCE_INFO PAL call to get purge local tc info to purge local tc. 
Yes, HV can get PAL_PTCE_INFO in advance to avoid this issue. But HV may call 
other PAL call directly. Eg. if VMM supports power management, HV may call 
PAL_HALT or PAL_LIGHT_HALT. So it's better to keep eager mapping.

>-----Original Message-----
>From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Xu, Anthony
>Sent: 2005年10月14日 10:26
>To: Magenheimer, Dan (HP Labs Fort Collins)
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable
>
>Yes, I think we can use lazy PAL mapping, for meeting deadline, we didn't
>carefully consider this.
>
>>-----Original Message-----
>>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
>>Sent: 2005年10月13日 20:49
>>To: Xu, Anthony
>>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>Subject: RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable
>>
>>Thanks!  Looks like you found some very difficult bugs!
>>
>>> - Changing lazy PAL mapping switch to eager switch per domain
>>> switch, since vti domain always depends on pal call.
>>
>>Can you explain this?  Aren't PAL calls always intercepted
>>by Xen even with VTI?  It seems that the lazy PAL mapping
>>approach should work for VTI also.  It's a shame to spend all
>>those cycles on every context switch when PAL calls are so rare
>>(after initial startup anyway).
>>
>>Thanks,
>>Dan
>>
>>> -----Original Message-----
>>> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
>>> Sent: Thursday, October 13, 2005 3:28 AM
>>> To: Magenheimer, Dan (HP Labs Fort Collins)
>>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>> Subject: [Xen-ia64-devel] [PATCH] fixed some bugs to make
>>> xen0 more stable
>>>
>>> Dan,
>>>
>>> When we debugged VTIdomainN, we found and fixed some bugs.
>>> This patch is based on ver 7332
>>>
>>> - Consistence of region id mangling algrithm:
>>>     - Metaphysical RID is not mangled, which may conflict
>>> with other domain's virtual RID
>>>     - Sometimes rr0 is mangled, but sometimes not
>>>     - Sometimes only rid value is saved to
>>> saved_rr0_metaphysical, but sometimes the whole value.
>>>
>>> - Nat bit consumption happens but handled as priv_emulate to
>>> forward progress.But this is definitely wrong. We found
>>> reason of nat consumption from fast_rfi,which doesn't save
>>> unat again after spill guest states, and then use guest unat
>>> to fill guest states when return.
>>>
>>> - In some corner case, timer interrupt handler won't update
>>> itm and then return directly. When that happens, machine
>>> timer interrupt disappears until guest timer interrupt sets
>>> v_itm actively. But vti domain depends on ac_timer while the
>>> latter will stop when above condition happens. Then if
>>> current context is vti domain, context switch disappears and
>>> machine halt.
>>>
>>> Also many compatibility issues to support non-vti and vti
>>> domain are solved,eg:
>>> - Changing lazy PAL mapping switch to eager switch per domain
>>> switch, since vti domain always depends on pal call.
>>> - evtchn_notify should also vcpu_wake target domain, since
>>> vti domain may block for io emulation. Xenolinux is free of
>>> this issue, since it's always runnable.
>>>
>>>
>>> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
>>> Signed-off-by Anthony Xu <anthony.xu@xxxxxxxxx>
>>>
>>>
>>> Thanks
>>> Anthony
>>>
>>>
>
>_______________________________________________
>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

<Prev in Thread] Current Thread [Next in Thread>