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] pv_ops progress & ask for suggestion

To: <linux-ia64@xxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] pv_ops progress & ask for suggestion
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Mon, 7 Apr 2008 17:47:38 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 07 Apr 2008 02:51:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: AciYlGo84mc7X5DoQj+oAU2B+hyYpw==
Thread-topic: pv_ops progress & ask for suggestion
Tony & all:
        Recently we have completed the IVT.s pv_ops by using dual
compile, and also many cleanups to simplify the changes to upstream
code. All the C code touching privilege instruction is replaced with
indirect function call (will be binary patched to use direct function
call in future), and IVT table is dual compiled to minimize impact to
native IVT table, but we get some dilemma in handling kernel/entry.S and
also generic policy for other ASM files.

        In entry.S, there are around 17 privilege instructions, some of
them must be paravirtualized including 2 cover instructions, and 1 "RFI"
(this one is due to Xen hypervisor issue). There are other 15 privilege
instructions (In Xen) such as CR access that could be paravirtualized
for performance reason.

        Now we have 2 choices:
        Alt1:  Dual compile entry.S like IVT.s (dual compile all ASM
files if it needs virtualization)
                pros: Same policy with iVT, use same MACRO to
replacement.
                cons: There are other ASM files such as
sn/kernel/pio_phys.S need to be dual compiled too.
                        And unlike IVT table, the memory occupied by
dual compiled code won't be able to be freed easily since the size is
not fixed. Also all future ASM code touch privilege instruction may need
to be dual compiled too.

        Alt2: Use indirect call like C code for non IVT nor gate page
code (dual compile only for IVT & gate page which has fixed size and
performance killer)
                Pros: flexible for future ASM code (just use same MACRO,
no dual compile requirement).
                Cons: 2 sets of solution for ASM code, and also slightly
performance lose due to indirect function call (future patching will
convert it to direct function call, or in place code.)
                

        Any suggestions?

        Thanks, 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>