From: Keith Owens <kaos@ocs.com.au>
To: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: Jack Steiner <steiner@sgi.com>,
linux-ia64@vger.kernel.org, "Dong, Eddie" <eddie.dong@intel.com>,
virtualization@lists.linux-foundation.org,
Robin Holt <holt@sgi.com>, Christoph Lameter <clameter@sgi.com>,
"Zhang, Xiantao" <xiantao.zhang@intel.com>,
xen-ia64-devel <xen-ia64-devel@lists.xensource.com>
Subject: Re: paravirt_ops support in IA64
Date: Tue, 19 Feb 2008 11:13:46 +1100 [thread overview]
Message-ID: <32163.1203380026@ocs10w> (raw)
In-Reply-To: Your message of "Mon, 18 Feb 2008 20:31:16 +0900." <20080218113116.GD8023%yamahata@valinux.co.jp>
Isaku Yamahata (on Mon, 18 Feb 2008 20:31:16 +0900) wrote:
>On Mon, Feb 18, 2008 at 11:28:41AM +0800, Dong, Eddie wrote:
>> 2: Same IVT source code, but dual/mulitple compile to generate
>> dual/multiple IVT table. I.e. we replace those primitive ops (sensitive
>> instructions) with a MACRO which uses compile option for different
>> hypervisor type.
>> The pseudo code of the MACRO could be: (take read CR.IVR
>> as example)
>>
>> AltA:
>> #define ASM_READ_IVR /* read IVR to GR24 */
>> #ifdef XEN
>> breg1 = return address
>> br xen_readivr
>> #else /* native
>> mov GR24=CR.IVR;
>> #endif
>> Or
>> AltB:
>> #define ASM_READ_IVR /* read IVR to GR24 */
>> #ifdef XEN
>> in place code of function xen_readivr
>> #else /* native
>> mov GR24=CR.IVR;
>> #endif
>>
>> From maintenance effort point of view, it is minimized,
>> but not exactly what X86 pv_ops look like.
>>
>> Both approach will cause code size issue, but altB is
>> much worse in this area, while AltA need one additional BR clobber
>> register
>
>
>Pros:
>- single code
>- hopefull less maintenance cost compared to #1
>
>Cons:
>- requires restriction on register usage. And we need to define its
> convension.
> When modifying ivt.S in the future after converting ivt.S,
> those convesion must be kept in mind.
>- suboptimal for paravirtualized case compared to #1 case
Please, please, please do _NOT_ hide register numbers inside small
macros like this. It makes it far too easy to miss register side
effects when looking at IA64 assembler code. Instead make the register
usage a parameter to the macro, so a human looking at the source code
can see which registers are being used. The macros in
include/asm-ia64/mca_asm.h are good examples of this approach. IOW
#define ASM_READ_IVR(breg, greg) ... move greg=cr.ivr
ASM_READ_IVR(breg1, gr24) # make it obvious which registers are hit
For large macros like SAVE_ALL there is no choice but to hide register
side effects inside the macro, but that should be the exception, not
the rule.
prev parent reply other threads:[~2008-02-19 0:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <10EA09EFD8728347A513008B6B0DA77A02C8234B@pdsmsx411.ccr.corp.intel.com>
2008-02-18 11:31 ` paravirt_ops support in IA64 Isaku Yamahata
[not found] ` <20080218113116.GD8023%yamahata@valinux.co.jp>
2008-02-18 15:43 ` Dong, Eddie
2008-02-19 0:13 ` Keith Owens [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32163.1203380026@ocs10w \
--to=kaos@ocs.com.au \
--cc=clameter@sgi.com \
--cc=eddie.dong@intel.com \
--cc=holt@sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=steiner@sgi.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xen-ia64-devel@lists.xensource.com \
--cc=xiantao.zhang@intel.com \
--cc=yamahata@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).