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] paravirt_ops and its alternatives

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] paravirt_ops and its alternatives
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 6 Feb 2008 15:14:08 +0800
Cc: "Luck, Tony" <tony.luck@xxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 05 Feb 2008 23:21:19 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080206015937.GJ22376%yamahata@xxxxxxxxxxxxx>
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>
References: <10EA09EFD8728347A513008B6B0DA77A02B655F0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <10EA09EFD8728347A513008B6B0DA77A02BA05B3@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <77F10470D44B4741A1E201C07B8B01F05D2C27@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <10EA09EFD8728347A513008B6B0DA77A02BA094A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1202154319.6709.32.camel@lappy> <77F10470D44B4741A1E201C07B8B01F05D307A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <10EA09EFD8728347A513008B6B0DA77A02BE560C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080205024455.GD22376%yamahata@xxxxxxxxxxxxx> <10EA09EFD8728347A513008B6B0DA77A02BE590A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080206015937.GJ22376%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchoZEfo404uUTtIT820BLhzEDm5ZgAKNkDw
Thread-topic: [Xen-ia64-devel] paravirt_ops and its alternatives
Isaku Yamahata wrote:
> On Tue, Feb 05, 2008 at 10:17:10PM +0800, Dong, Eddie wrote:
>>      1: The coding style is not as good as original IVT code.
> 
> I have to agree with you here.
> 
> 
>>              For example:
>> #ifdef CONFIG_XEN
>>         mov r24=r8
>>         mov r8=r18
>>         ;;
>> (p10)   XEN_HYPER_ITC_I
>>         ;;
>> (p11)   XEN_HYPER_ITC_D
>>         ;;
>>         mov r8=r24
>>         ;;
>> #else
>>              This kind of save/restore R8 in each replacement (MACRO)
>>      is kind of not well tuned. We probably need a big IVT code
change
>>      to avoid frequent save/restore in each MACRO.
>> 
>>              This needs many effort. Of course taking shortcut before
>> 
>> into upstream.
> 
> Yes, such register value save/restore is suboptimal.

Another issue from me is that why we use R8/R9 for In/Out parameter
in Xen static hypercall. This raises us an issue to save/restore R8/R9
using
bank 0 register. static PAL call doesn't use R8/R9, should we?
Especially
pv_ops itself is Xen neutral.


> I'm guessing such overhead is relatively small compared to the
> hyperprivops overhead which issues break instruction. 

Yes, the overhead is mostly un-observable, but mainly coding style or 
code quality concern. I assume Linux guys is much more paranoid in
pursuing "best".

> So presumably for reducing such overhead, it is necessary to replace
> those break instructions with fast hyperprivops using gate page. Such
> optimization would be the next step after upstream merge though. 

Yes, this could be future effort, actually this is not a pv_ops work,
but
xen wrapper work. 

Let me create another thread for compile time dual IVT table vs. single
discussion.
thx, eddie

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