xen-ia64-devel
RE: [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>
|
- [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Xu, Anthony
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Xu, Anthony
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Xu, Anthony
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Xu, Anthony
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable,
Xu, Anthony <=
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Xu, Anthony
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Xu, Anthony
- RE: [Xen-ia64-devel] [PATCH] fixed some bugs to make xen0 more stable, Magenheimer, Dan (HP Labs Fort Collins)
|
|
|