[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-ia64-devel] per hypervisor IVT table vs. global IVT table


  • To: "xen-ia64-devel" <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Wed, 6 Feb 2008 15:32:37 +0800
  • Cc: "Luck, Tony" <tony.luck@xxxxxxxxx>
  • Delivery-date: Tue, 05 Feb 2008 23:39:26 -0800
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AchoknJD5PFZNlpgS/WOFNHG3uIAdw==
  • Thread-topic: per hypervisor IVT table vs. global IVT table

All:
        If we use single IVT table, the pv_ops code will look like:

ALT0:
        breg0 = pv_ops base
        breg0 += offset for this pv_ops
        breg1 = return address;
        br  breg0.              /* pv_ops clobbered breg0/breg1 */

        That means we have to use 2 BR clobber register.

        Or we can use X86 hypercall page like technique to copy those
hooks
to a common page to avoid breg0. This make ALT0 same with following
ALT1.

        If we use per hypervisor IVT table at compile time. We could do:

ALT1:
#define ASM_READ_IVR
#if XEN
        breg1 = return address
        br    pv_ops_api_readivr
#endif
        When pv_ops_api_readivr is hooked, it do read_ivr_code.

        Or we can just do:

ALT2:
#define ASM_READ_IVR
#ifdef XEN
        read_ivr_code
#endif

        ALT1 is more like X86 pv_ops that some initialization code will
hook,
ALT2 can save an additional br register, and thus probably less change
to Linux
IVT code.
        In terms of former approach, binary patching can patch ALT1 code
back
to ALT2 solutuon to avoid the indirection call cost if we follow same
approach 
with X86.
        Which ALT should we pursue first?
thx, eddie

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.