All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Knorr <kraxel@suse.de>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: Hypercall interface changes for PAE
Date: 01 Jun 2005 11:17:02 +0200	[thread overview]
Message-ID: <87hdgi8mi9.fsf@bytesex.org> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D281FC7@liverpoolst.ad.cl.cam.ac.uk>

"Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> writes:

> > But it is greatly simplified, IIUC. If the hypercalls are 
> > binary compatible then you have only one set of hypercall 
> > interface functions and types, and switching between two 
> > *implementations* of pagetable-related stuff (only the things 
> > that actually need to be different) is quite straightforward.
> 
> For the same reason that Linux doesn't support run-time switching
> between PAE and non-PAE kernels, doing the same on Xen is going to be an
> equivalent pain in the butt.

Fully agree on the xen kernel side.  The performance hit a runtime
switch would have likely is bigger than simply running PAE all the
time ;)

I don't thing the performance argument is that important for the xen
tools though.  Booting or migrating a domain is a rare event (when
compared to the page table manipulations the xen kernel has to do all
the time).

> The only way it can reasonably be done cleanly and with decent
> performance is double compilation of the relevant mm functions in Xen
> (and libxc too). In which case, having separate hypercall vectors makes
> most sense.

Well, I'd try to get away without double compilation for libxc.

But you guys know that part of the code much better than I do, so if
you think double compilation is the best way to deal with it, lets
take that route.

cheers,

  Gerd

-- 
-mm seems unusually stable at present.
	-- akpm about 2.6.12-rc3-mm3

  reply	other threads:[~2005-06-01  9:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-31 22:42 Hypercall interface changes for PAE Ian Pratt
2005-06-01  9:17 ` Gerd Knorr [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-06-01  9:30 Ian Pratt
2005-06-01 10:04 ` Keir Fraser
2005-05-30 12:52 network (irq?) problems in unstable Gerd Knorr
2005-05-30 13:36 ` Keir Fraser
2005-05-31 10:18   ` Gerd Knorr
2005-05-31 10:59     ` Keir Fraser
2005-05-31 11:36       ` Gerd Knorr
2005-05-31 18:21         ` Hypercall interface changes for PAE Keir Fraser
2005-05-31 18:26           ` Keir Fraser
2005-05-31 19:02             ` Gerd Knorr
2005-05-31 19:23               ` Keir Fraser
2005-05-31 20:38                 ` Gerd Knorr
2005-05-31 21:18                   ` Keir Fraser
2005-05-31 21:40                     ` Keir Fraser
2005-05-31 22:25                 ` David Hopwood
2005-05-31 18:32           ` Jonathan S. Shapiro
2005-05-31 18:37             ` Keir Fraser

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=87hdgi8mi9.fsf@bytesex.org \
    --to=kraxel@suse.de \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /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.