From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Knorr Subject: Re: PAE xen + linux kernel boots ... Date: Sun, 1 May 2005 01:15:30 +0200 Message-ID: <20050430231530.GE8637@bytesex> References: <20050425172624.GB22076@bytesex> <87ll74o29m.fsf@bytesex.org> <20050430090117.GC16883@us.ibm.com> <20050430095123.GE16883@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20050430095123.GE16883@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Scott Parish Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > On the linux side of things we have the following in pgtable-3level.h: > > #if 1 /* writable pagetables */ > static inline void set_pte(pte_t *ptep, pte_t pte) > { > ptep->pte_high = pte.pte_high; > smp_wmb(); > ptep->pte_low = pte.pte_low; > } > ... Note there is also set_pte_atomic ... > Switch to xen, which is going to emulate some instructions and fake > the writing. We eventually end up in ptwr_emulated_update(), who among > other things, tries to copy the full l1_pgentry_t (64bits), but from > the 4 byte offset, that is the 4 high bytes and then 4 bytes of > undefined memory that may even be in another page. Having a close look at the emulation is on my todo list. Note that ptwr_emulated_update takes "unsigned long", i.e. 32-bit values (on x86_32) as parameters, so chances are pretty good that there are issues with 64bit updates. It works fine for me nevertheless, for some reason, maybe just pure luck ;) Turning off emulation works fine for me as well btw. (just delete the tree lines which force the emulation path for PAE), so I obviously got the PGT_va backref stuff right ;) Gerd PS: there is revision #6 of the patches on the usual location, I hadn't announced those yet. -- #define printk(args...) fprintf(stderr, ## args)