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: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Subject: Re: [Xen-ia64-devel] paravirt_ops and its alternatives
From: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Date: Tue, 5 Feb 2008 11:44:55 +0900
Cc: "Luck, Tony" <tony.luck@xxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 04 Feb 2008 18:45:10 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <10EA09EFD8728347A513008B6B0DA77A02BE560C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
On Tue, Feb 05, 2008 at 07:41:05AM +0800, Dong, Eddie wrote:
> Yang, Fred wrote:
> > Alex Williamson wrote:
> >> On Mon, 2008-02-04 at 09:53 +0800, Dong, Eddie wrote:
> >>> Yang, Fred wrote:
> >>>> Dong, Eddie wrote:
> >>>>> Re-post it to warmup discussion in case people can't read PPT
> >>>>> format,
> >>>> 
> >>>> IVT is very performance sensitive for the native Linux, how about
> >>>> dual IVT tables alternative for CPU virtualization?  It would need
> >>>> maintainance effort but it would be much cleaner forIA64 situation.
> >>>> -Fred
> >>> 
> >>> Dual IVT table could be a night mare for Tony, I guess. But yes we
> >>> need to have more active discussion to kick it off.
> >> 
> >>    Yes, two separate IVTs with 95+% of the code being the same would
> >> not be ideal.  I think we should aim for a single ivt.S that gets
> >> compiled a couple times with different options, once for native and
> >> again for each virtualization option.  It looks like more than half
> >> of the changes in xenivt.S could be easily converted to macros that
> >> could be switched by compile options.  Perhaps a pattern will emerge
> >> for the rest.
> > If it is not necessarily to stick with a single image and runtime to
> > determine code path, multi-compile paths to generate different PV or
> > native image then macros can possibly work.. -Fred 
> 
> Dual compile could be a good approach. Another alternative will be X86
> pv_ops like dynamic binary patching per compile time hints. The later 
> method also uses macro for those different path, but this macro will 
> generate a special section including the information for runtime patch
> base on pv_ops hook. (some kind of similar to Yamahata's binary
> patch method though it addresses C side code)
> 
> With dynamic pv_ops patch, the native machine side will again see
> original single instruction + some nop. So I guess the performance lose
> will be very minor. Both approach is very similar and could be left
> to Linux community's favorite in future :)

Actually already we adopted dual compilatin approach for gate page.
See gate.S in xenLinux arch/ia64/kernel/gate.S and Makefile.
I'm guessing that dual compiling approach is easier than binary
patching approach because some modification of xenivt.S doesn't 
correspond to single instruction.
Yes I agree that we can go for either way according to upstream favor.


> Another problem I want to raise is about pv_ops calling convention.
> Unlike X86 where stack is mostly available, IPF ASM code such as
> IVT entrance doesn't invoke stack, so I think we have to define 
> static registers only pv_ops & stacked registers pv_ops like PAL.

With respect to hypervisor ABI, we have already differentiate them.
ia64 specific HYPERVIRVOPS as static registers convention and
normal xen hypercall as stacked registers convention.


> For most ASM code (ivt), it have to use static registers only pv_ops.
> We need to carefully define the clobber registers used and do 
> manual modification to Linux IVT.s. Dual IVT table or binary 
> patching is preferred for performance.
> 
> Stacked register pv_ops could follow C convention and it is less
> performance critical, so probably no need to do dynamic patching.

I'm guessing one important exception is masking/unmasking interrupts.
i.e. ssm/rsm psr.i. Anyway we will see during our merge effort.

-- 
yamahata

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