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/
Home Products Support Community News


RE: [Xen-ia64-devel] Re: [Xen-devel] XenLinux/IA64 domU forward port

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] Re: [Xen-devel] XenLinux/IA64 domU forward port
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Fri, 15 Feb 2008 00:43:14 +0800
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 14 Feb 2008 08:58:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080214100134.GB8464%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: <20080214070957.GA8464%yamahata@xxxxxxxxxxxxx> <10EA09EFD8728347A513008B6B0DA77A02C430E5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080214100134.GB8464%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Achu8Ryj8ZpDzGfoSF6QxtQtTuqJGwANEcuw
Thread-topic: [Xen-ia64-devel] Re: [Xen-devel] XenLinux/IA64 domU forward port
I agree with your catagory, but I think #C is the 1st challenge  we 
need to address for now. #A could be a future task for performance
 later after pv_ops functionality is completed. I don't worry about
 those several cycles difference in the primitive ops right now,
 since we already spend 500-1000 cycles to enter the C code.

The major challenge to #C is listed in my previous thread, it is not
an easy thing to address for now, especially if we need to change
original IVT code a lot.

Another big challenge is machine vector. I would like to create a
thread to discuss it some time later. Basically it has something overlap
with pv_ops. 

>> We can't destroy non bank0 register in interrupt/exception handler
>> before memory based storage is involved to save/restore them.
>> That is why I'd like to limit those parameters to bank0 registers.
>> For current Xen, it is using kind of C ABI (i.e. R8/R9), we can argu
>> if it is best, but should be easy to commodate both.
> This discussion is for category C binary patching.
> At this moment I'm not sure if it can be done performance effectively.
> If the upstream requires it we can go for it, off course.

If pv_ops is there, Xen can be easily changed to do this, for example
pv_ops_init can tell hypervisor it is on pv_ops, hypervisor can then 
adopt the new ABI. For now, we can simply do that in hypervisor 
wrapper (i.e. switch to R8/R9 in the wrapper).

I didn't get a concret proposal yet, just share what I have so far, 
where I suggest to do staged approach to make the turn over 
as early as possible. See the attachment pls.

thx, eddie

Attachment: paravirt_ops2.pdf
Description: paravirt_ops2.pdf

Xen-ia64-devel mailing list