From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Knorr Subject: Re: Hypercall interface changes for PAE Date: 01 Jun 2005 11:17:02 +0200 Message-ID: <87hdgi8mi9.fsf@bytesex.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org "Ian Pratt" 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