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

[Xen-ia64-devel] RE: [PATCH 04/15] ia64/pv_ops: introduce pv_info which

To: "Jes Sorensen" <jes@xxxxxxx>
Subject: [Xen-ia64-devel] RE: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Tue, 22 Apr 2008 21:15:26 +0800
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, linux-ia64@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 22 Apr 2008 06:15:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <480DCC3A.1010007@xxxxxxx>
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: <1207716548202-git-send-email-yamahata@xxxxxxxxxxxxx> <12077165491881-git-send-email-yamahata@xxxxxxxxxxxxx> <yq04p9ul05i.fsf@xxxxxxxxxxxxxx> <20080422100219.GG28863%yamahata@xxxxxxxxxxxxx> <480DBFD2.9060600@xxxxxxx> <10EA09EFD8728347A513008B6B0DA77A031466E7@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <480DCC3A.1010007@xxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcikbDijyA15EqP4TxmdLmlSyxQtCwADVVig
Thread-topic: [PATCH 04/15] ia64/pv_ops: introduce pv_info which describes some random info.
Jes Sorensen wrote:
> Dong, Eddie wrote:
>>> Rather than making these binary patches, why not make them fast
>>> syscalls and using a vdso page. Some of the priviledged instructions
>>> are simply reads and we could have that information in a read-only
>>> data page, so there is no need to do a context switch at all. Others
>>> could benefit from a fast system call that doesn't do a full context
>>> switch.
>> 
>> The issue is we don't want to change Linux code a lot, otherwise it
>> won't be accepted. If we use same logic with original Linux,
>> but it is using indirect function call now, binary patching could
>> help in performance.
> 
> Hi Eddie,
> 
> Sorry but this is a wrong assumption. If the code is correct then
> there is no reason why it will not be accepted. It's far more
> important to avoid ugly clutter that makes the code hard to maintain.
> 

My understanding is that code such as IVT table are well tuned and you
are really 
difficult to pursuade people to replace those privilege resource access
instruction
to use vdso or something equalvalent such as mov GRx=CRy.  For those C
code
previlige resource access, like Isaku mentioned, we need to consider
native too.

Anyway binary patching is just an optimization that X86 used and there
is no 
reason IA64 can't take. At least replacing indirect function with direct
function
call. 

Eddie

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

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