From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [Xen-devel] Physical memory start contraints in the Linux kernel (Was: Re: Xen osstest on Calxeda midway progress (Was: Re: [xen-unstable test] 21486: tolerable FAIL - PUSHED)) Date: Tue, 12 Nov 2013 14:52:00 +0000 Message-ID: <52824090.8040203@linaro.org> References: <1384250005.1883.35.camel@kazak.uk.xensource.com> <201311121437.55826.arnd@arndb.de> <52823C9E.2010007@linaro.org> <20131112144128.GL16735@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131112144128.GL16735@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Russell King - ARM Linux Cc: xen-devel@lists.xensource.com, Ian Campbell , Arnd Bergmann , Stefano Stabellini , "xen.org" , Andre Przywara , Stefano Stabellini , Olof Johansson , linux-arm-kernel@lists.infradead.org List-Id: xen-devel@lists.xenproject.org On 11/12/2013 02:41 PM, Russell King - ARM Linux wrote: > On Tue, Nov 12, 2013 at 02:35:10PM +0000, Julien Grall wrote: >> During some debugging on the Arndale and Midway, I found another >> constraint with CONFIG_ARM_PATCH_PHYS_VIRT. >> I have noticed that all the kernel physical addresses must be lower than >> the corresponding virtual addresses. So the delta offset compute in >> __fixup_pv_table (arch/arm/kernel/head.S) must always be negative. >> If this assertion is not validated, when the kernel will browse the >> memory bank (sanity_check_info in arch/arm/mm/mmu.c), __phys(...) will >> compute a wrong address and will result to consider all memory bank as >> highmem. >> >> After digging in the code, it seems it's due to some optimization during >> opcode fixup in __fixup_a_pvtable. Is it a wanted constraint? > > Are you talking about the code in v3.12 or the code in -next ? I was talking about 3.12. I have just checked -next and my issue seems to be fixed by the commit f52bb722547f43caeaecbcc62db9f3c3b80ead9b. I should have checked earlier, thanks. -- Julien Grall