From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEges-0008L3-OL for qemu-devel@nongnu.org; Mon, 13 Jul 2015 12:32:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEger-0005tQ-J1 for qemu-devel@nongnu.org; Mon, 13 Jul 2015 12:32:46 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49217 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEger-0005si-C8 for qemu-devel@nongnu.org; Mon, 13 Jul 2015 12:32:45 -0400 Message-ID: <55A3E82B.2080204@suse.de> Date: Mon, 13 Jul 2015 18:32:43 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1436802997-170244-1-git-send-email-agraf@suse.de> <55A3E559.7060704@suse.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2.4] hw/arm/boot: Increase fdt alignment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On 07/13/15 18:27, Peter Maydell wrote: > On 13 July 2015 at 17:20, Alexander Graf wrote: >> On 07/13/15 18:13, Peter Maydell wrote: >>> On 13 July 2015 at 16:56, Alexander Graf wrote: >>>> The Linux kernel on aarch64 creates a page table entry at early bootup >>>> that spans the 2MB range on memory spanning the fdt start address: >>>> >>>> [ ALIGN_DOWN(fdt, 2MB) ... ALIGN_DOWN(fdt, 2MB) + 2MB ] >>>> >>>> This means that when our current 4k alignment happens to fall at the end >>>> of the aligned region, Linux tries to access memory that is not mapped. >>>> >>>> The easy fix is to instead increase the alignment to 2MB, making Linux's >>>> logic always succeed. >>> This is a kernel bug and should be fixed there. The booting >>> protocol document is pretty clear: >>> https://www.kernel.org/doc/Documentation/arm64/booting.txt >>> >>> "The device tree blob (dtb) must be placed on an 8-byte boundary" >> >> While I tend to agree, we can't fix old / released kernels. So maybe we >> should just fix it in both? > Maybe. The trouble with just bumping up the alignment though is that > not all boards have so much RAM that they can trivially waste another > meg or two on alignment padding without noticing it. AArch64 boards > are probably OK but some of the old 32 bit boards are not anywhere > near as well supplied with RAM. Picking dtb alignment based on 32/64 > bits might be safer. How about we just align it to the next log2 of the dtb size? That should solve all problems and be good enough for low mem boards too. Alex