From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGozB-00081a-LJ for qemu-devel@nongnu.org; Thu, 29 Jan 2015 08:18:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGoz8-0002WA-F3 for qemu-devel@nongnu.org; Thu, 29 Jan 2015 08:18:17 -0500 Message-ID: <54CA3198.3060603@suse.de> Date: Thu, 29 Jan 2015 14:11:52 +0100 From: Alexander Graf MIME-Version: 1.0 References: <1422282118-22507-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <20150129004847.GK14681@voom> In-Reply-To: <20150129004847.GK14681@voom> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-ppc: Use right page size with hash table lookup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , "Aneesh Kumar K.V" Cc: qemu-ppc@nongnu.org, paulus@samba.org, Anton Blanchard , qemu-devel@nongnu.org On 29.01.15 01:48, David Gibson wrote: > On Mon, Jan 26, 2015 at 07:51:58PM +0530, Aneesh Kumar K.V wrote: >> We look at two sizes specified in ISA (4K, 64K). If not found matching, >> we consider it 16MB. >> >> Without this patch we would fail to lookup address above 16MB range. >> Below 16MB happened to work before because the kernel have a liner >> mapping and we always looked up hash for 0xc000000000000000. The >> actual real address was computed by using the 16MB offset >> with the real address found with the above hash. >> >> Without Fix: >> (gdb) x/16x 0xc000000001000000 >> 0xc000000001000000 : Cannot access memory at address 0xc000000001000000 >> (gdb) >> >> With Fix: >> (gdb) x/16x 0xc000000001000000 >> 0xc000000001000000 : 0x00000000 0x00000000 0x00000000 0x00000000 >> 0xc000000001000010 : 0x00000000 0x00000000 0x00000000 0x00000000 >> 0xc000000001000020 : 0x00000000 0x00000000 0x00000000 0x00000000 >> 0xc000000001000030 : 0x00000000 0x00000000 0x00000000 0x00000000 >> >> Signed-off-by: Aneesh Kumar K.V > > This doesn't fully implement the sllp page size encodings, but it's > certainly better than what's there now. > > Reviewed-by: David Gibson Thanks, applied to ppc-next. Alex