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

To: "Yang, Fred" <fred.yang@xxxxxxxxx>, "Alex Williamson" <alex.williamson@xxxxxx>
Subject: RE: [Xen-ia64-devel] paravirt_ops and its alternatives
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Tue, 5 Feb 2008 07:41:05 +0800
Cc: "Luck, Tony" <tony.luck@xxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 04 Feb 2008 15:41:26 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <77F10470D44B4741A1E201C07B8B01F05D307A@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>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchnZrCu1mmfk2i2RkSAhBpb5JEg1gAAla4gAAba04A=
Thread-topic: [Xen-ia64-devel] paravirt_ops and its alternatives
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 :)

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.

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.

more comments are welcome:)

Xen-ia64-devel mailing list