All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [kvm-ia64-devel] [PATCH 0/4] ia64/xen: paravirtualization of hand written assembly code
Date: Mon, 25 Feb 2008 13:33:12 +0000	[thread overview]
Message-ID: <25065.1203946392@ocs10w> (raw)
In-Reply-To: <12039094061834-git-send-email-yamahata@valinux.co.jp>

tgingold@free.fr (on Mon, 25 Feb 2008 13:54:48 +0100) wrote:
>Quoting Keith Owens <kaos@ocs.com.au>:
>{...}
>> A combination of options (2) and (3) would work.  Have a single source
>> file for the IVT, using conditional macros.  Use that source file to
>> build (at least) two copies of the IVT, for native and any virtualized
>> modes.  The native copy of the IVT starts at label ia64_ivt in section
>> .text.ivt, as it does now.  Any IVT versions for virtualized mode are
>> defined as __cpuinitdata, so they are discarded after boot, unless
>> CONFIG_HOTPLUG_CPU=y.  arch/ia64/kernel/head.S copies the relevant
>> virtualized version over ia64_ivt when necessary, before initializing
>> cr.iva.
>>
>> Single source for maintenance.  No indirect function overhead at run
>> time.  Binary patching at boot time for the right mode.  No wasted
>> space in the kernel.
>
>Good idea.  The linker script will be slightly more complex however...

Don't see why the linker script needs to change at all.  The existing
native IVT is at label ia64_ivt in section .text.ivt, as it is now.
arch/ia64/kernel/head.S simply overwrites ia64_ivt with 32K of data for
the virtualized IVT, copying from another data area.  AFAICT, nothing
in that process requires linker changes.


  parent reply	other threads:[~2008-02-25 13:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25  3:16 [PATCH 0/4] ia64/xen: paravirtualization of hand written assembly code Isaku Yamahata
2008-02-25  3:16 ` [PATCH 1/4] ia64/xen: paravirtualize ivt.S fault handlers, " Isaku Yamahata
2008-02-25  3:16 ` [PATCH 2/4] ia64/xen: paravirtualize minstate.h, DO_SAVE_MIN Isaku Yamahata
2008-02-25  3:16 ` [PATCH 3/4] ia64: prepare for paravirtualizatin of entry.S Isaku Yamahata
2008-02-25  3:16 ` [PATCH 4/4] ia64/xen: paravirtualize ia64_switch_to, ia64_leave_syscall and ia64_leave_kernel in entry.S Isaku Yamahata
2008-02-25  4:18 ` [PATCH 0/4] ia64/xen: paravirtualization of hand written assembly code Keith Owens
2008-02-25 12:54   ` [kvm-ia64-devel] " tgingold
2008-02-25 18:32   ` [kvm-ia64-devel] [PATCH 0/4] ia64/xen: paravirtualization ofhand " Dong, Eddie
2008-02-25  4:18 ` [PATCH 0/4] ia64/xen: paravirtualization of hand " Keith Owens
2008-02-25 12:54 ` [kvm-ia64-devel] " tgingold
2008-02-25 13:33   ` Keith Owens
2008-02-25 13:33 ` Keith Owens [this message]
2008-02-25 15:04   ` tgingold
2008-02-25 15:04 ` tgingold
2008-02-26  2:35   ` Keith Owens
2008-02-25 18:32 ` [kvm-ia64-devel] [PATCH 0/4] ia64/xen: paravirtualization ofhand " Dong, Eddie
2008-02-26  2:35 ` [kvm-ia64-devel] [PATCH 0/4] ia64/xen: paravirtualization of hand " Keith Owens

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=25065.1203946392@ocs10w \
    --to=kaos@ocs.com.au \
    --cc=linux-ia64@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.