From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: 2.6.20.3 to be the next kernel? Date: Mon, 04 Jun 2007 21:50:08 -0700 Message-ID: <4664EB80.2080509@goop.org> References: <1180961068.5786.188.camel@localhost.localdomain> <200706042058.37449.mark.williamson@cl.cam.ac.uk> <466472E4.9000505@goop.org> <200706050324.26723.mark.williamson@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200706050324.26723.mark.williamson@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mark Williamson Cc: tim.post@netkinetics.net, xen-devel@lists.xensource.com, "Daniel P. Berrange" , Ian Campbell List-Id: xen-devel@lists.xenproject.org Mark Williamson wrote: > I was wondering how you handle PAE in pv-ops. Presumably you just toggle > based on what the kernel was built for? It seems like PV-ops ought in > principle to be able to make the kernel bimodal. I'm guessing the > appropriate response to my question is probably a simple "patches > welcome" ;-) Indeed. Actually, its something I gave some thought to, but unfortunately it isn't that simple. The main problem is that the types of pte_t/pmd_t/pgd_t change from 32 to 64 bit, and all the pmd folding stuff is still done at compile-time. I was also thinking about always using the PAE forms of the structures, and actually do the conversion just as we read/write the entries. But even then, the various pagetable accessors/traversal functions know how large the entries are and how many levels the pagetables have, etc. The only slightly workable approach I thought of was to maintain a sort-of in-kernel shadow pagetable scheme, which maintains parallel PAE and non-PAE pagetables. But that's hardly elegant, and poses all sorts of its own problems (like propagating the hardware-set access/modified bits properly, for example). So, its all a bit of an open question. J