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

RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps


  • To: "Tristan Gingold" <tgingold@xxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Wed, 12 Mar 2008 13:59:09 +0800
  • Cc: Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 13 Mar 2008 05:26:56 -0700
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AciDWOdBIraFmzAfScq3vNJQ5xdUcwArPoUg
  • Thread-topic: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps

Tristan Gingold wrote:
> Hi,
> 
> just a point about call convention: I don't think switching to PAL
> static convention is a good idea as it doesn't work well with xen
> hyperprivop because of banked registers.
> 
> Tristan.

Tristan:
        This is for pv_ops interface calling convention, not hypervisor
API convention. The hypervisor wrapper will convert from pv_ops
convention to hypervisor convention. pv_ops is hypervisor neutral.

        BTW, since we use single source, dual compile to generate code
in place. Actually those pv_cpu_asm_ops won't be used frequently, most
of them are not used. So even we use this policy, it is very few place
which may use a formal pv_ops for ASM code which imply the calling
convention.  All IVT/gate table/page doesn't have this issue.

        Does this solve your concern?

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