Subject: Re: [PATCH RFC WIP] x86/paravirt: add register-saving thunks to
	reduce caller register pressure
From: Zachary Amsden <zach@vmware.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ian Campbell <Ian.Campbell@citrix.com>,
       Ingo Molnar <mingo@elte.hu>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <4980A07D.3010008@goop.org>
References: <4980A07D.3010008@goop.org>
Content-Type: text/plain
Date: Wed, 28 Jan 2009 15:05:03 -0800
Message-Id: <1233183903.16317.242.camel@bodhitayantram.eng.vmware.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1540
Lines: 40

On Wed, 2009-01-28 at 10:14 -0800, Jeremy Fitzhardinge wrote:
> Hi Guys,

> Zach: I wasn't really sure of what the VMI ABI calling convention is, so
> I haven't converted VMI yet.  I wasn't sure if it needs a register
> saving thunk to wrap the calls, or if they're guaranteed to not trash
> anything other than eax/rax.  Please advise.

C-like, allowing C or assembly implementations of calls.  Currently
several of the most important calls have a restricted clobber set,
however, and since it's clear there aren't any forthcoming new
implementations of a VMI ROM, it might be better to go with the actual
clobbers for performance critical ops.

> Standard calling convention is:
>          arguments          return      scratch
> x86-32   eax edx ecx        eax         ?

ecx, edx

> The most common paravirt ops, both statically and dynamically, are
> interrupt enable/disable/save/restore, so handle them first.  This is
> particularly easy since their calls are handled specially anyway.

> XXX Deal with VMI.  What's their calling convention?

Enable/Disable have no clobbers at all.
Save clobbers only return value, %eax
Restore also clobbers nothing.

The patching code has gotten quite complex with the 32/64 union; let me
apply it first and see before I comment on the patch.

Zach

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/