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] fully virtualize psr and ipsr on non-VTIdom

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH] fully virtualize psr and ipsr on non-VTIdomain
From: "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Date: Thu, 1 Dec 2005 19:58:21 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 01 Dec 2005 11:58:07 +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: AcXzytgKo6So03GTShmzfLz5ceuCSgBxm7VwAAi6/CAALSrUwA==
Thread-topic: [Xen-ia64-devel] [PATCH] fully virtualize psr and ipsr on non-VTIdomain
Dan,
My patch is intended to make functions like vcpu_get_psr, vcpu_set_psr_l, 
vcpu_ssm, vcpu_rsm, reflection_interrupt correct and clear, and it will not add 
extra overhead.

In your email "Next phase of Xen/ia64 development... ",
Performance tuning is last item. Stability and function implementation have 
higher priority, I totally agree. As for FAST_RFI, FAST_BREAK, 
FAST_ACCESS_REFLECT, corresponding C functions are rewritten in assembly code, 
and are run in guest context, yes it improve performance remarkably, these 
FAST** path doesn't need save/restore guest state and switch between bank0 and 
bank1, I can understand. But I think these should be parts of performance 
tuning and these should be done after HV have implemented necessary components 
and have been considerably stable. 
Currently HV is not stable enough, is changed frequently and community members 
may have other idea which they want to take a try, if every time when they want 
to do some modification or try new method or algorithm, they must make sure all 
the FAST** work well, which is a huge burden to developer.
For example, vhpt performance is very good under current Mangle algorithm, if I 
want to try some other Mangle algorithm, I must modify ten more place (where 
use Mangle algorithm in assembly) in FAST** path.
So, IMO we can turn off all FAST** path temporarily, which will make our work 
easy. Because FAST** path are turned off temporarily, performance degradation 
are also temporary. At current stage, we should put correctness and flexibility 
in the highest position.


Thanks
-Anthony


>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
>Sent: 2005年11月30日 21:50
>To: Xu, Anthony
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-ia64-devel] [PATCH] fully virtualize psr and ipsr on
>non-VTIdomain
>
>I'm still catching up after being gone for a few days and
>spent most of yesterday recovering from a trashed disk
>on my test machine.  My first priority is to find out
>what broke Xen/ia64 in xen-unstable so we have a solid
>foundation, then I will catch up on the patch backlog.
>
>In the meantime, please look at what your patch broke in
>FAST_RFI, FAST_BREAK, and FAST_ACCESS_REFLECT, as I won't
>be checking in patches with significant performance
>regressions.
>
>Thanks,
>Dan
>
>> -----Original Message-----
>> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
>> Sent: Wednesday, November 30, 2005 2:36 AM
>> To: Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins)
>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [Xen-ia64-devel] [PATCH] fully virtualize psr
>> and ipsr on non-VTIdomain
>>
>> Dan,
>>
>> What's your opinion about this patch?
>>
>> Thanks
>> -Anthony
>>
>> >-----Original Message-----
>> >From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> >[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On
>> Behalf Of Xu, Anthony
>> >Sent: 2005年11月28日 11:22
>> >To: Magenheimer, Dan (HP Labs Fort Collins)
>> >Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> >Subject: [Xen-ia64-devel] [PATCH] fully virtualize psr and ipsr on
>> >non-VTIdomain
>> >
>> >Dan,
>> >This patch is intended to fully virtualize psr and ipsr on non-VTI
>> >domain.
>> >Following things are done in this patch.
>> >1, previously when guest reads psr, it always get psr dt rt
>> it equal to
>> >1. that is because HV doesn't restore these information,
>> >metaphysical_mode can't present all these information. I save these
>> >information into privregs->vpsr. Thus guest can get correct
>> information
>> >about dt, rt and it.
>> >2, when guest reads psr, we should only return low 32bits
>> and 35 and 36
>> >bits, previously return all bits.
>> >3, when guest rsm and ssm psr, HV rsm and ssm some bits of
>> current psr
>> >which is used by HV, that is not correct, guest rsm and ssm
>> should only
>> >impact guest psr(that is regs->ipsr).
>> >4, mistakenly uses guest DCR, guest DCR should impact guest psr when
>> >injecting interruption into guest, but not impact guest ipsr.
>> >When injecting interruption into guest,The current implementation is
>> >    Guest ipsr.be=guest dcr.be
>> >    Guest ipsr.pp=guest dcr.pp
>> >Correct implementation should be,
>> >    Guest psr.be=guest dcr.be
>> >    Guest psr.pp=guest dcr.pp.
>> >
>> >Because of above modifications, I turn off FAST_RFI, FAST_BREAK and
>> >FAST_ACCESS_REFLECT.
>> >
>> >Signed-off-by Anthony Xu < anthony.xu@xxxxxxxxx>
>> >
>> >One question, why do we need to virtualize guest psr.pp and
>> always set
>> >guest psr.pp to 1?
>> >
>> >Thanks
>> >-Anthony
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>

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

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