From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPoZa-0006hl-Pb for qemu-devel@nongnu.org; Tue, 18 Mar 2014 03:36:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPoZS-0007gY-D0 for qemu-devel@nongnu.org; Tue, 18 Mar 2014 03:36:30 -0400 Received: from mail-ee0-x22e.google.com ([2a00:1450:4013:c00::22e]:55085) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPoZS-0007gN-3g for qemu-devel@nongnu.org; Tue, 18 Mar 2014 03:36:22 -0400 Received: by mail-ee0-f46.google.com with SMTP id t10so4892238eei.5 for ; Tue, 18 Mar 2014 00:36:20 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5327F771.7040205@redhat.com> Date: Tue, 18 Mar 2014 08:36:17 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20140317215455.2f14b61f@redhat.com> <5327F398.7040509@siemens.com> In-Reply-To: <5327F398.7040509@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-2.0?] target-i386: fix gdb debugging with large memory guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka , Luiz Capitulino , qemu-devel Cc: peter.maydell@linaro.org, afaerber@suse.de Il 18/03/2014 08:19, Jan Kiszka ha scritto: > On 2014-03-18 02:54, Luiz Capitulino wrote: >> If you start a Linux guest with more than 4GB of memory and try to look at a >> memory address, you will get an error from gdb: >> >> (gdb) p node_data[0]->node_id >> Cannot access memory at address 0xffff88013fffd3a0 >> (gdb) > > I suppose this is x86-64, not 32-bit with PTE, right? > >> >> I debugged this down to x86_cpu_get_phys_page_debug(), it doesn't handle the >> case where the PDPTE has the PS bit set (although I didn't check where Linux >> sets that bit). This commit adds the PS bit handling, which fixes the problem >> for me. >> >> Signed-off-by: Luiz capitulino >> --- >> >> Two observations: >> >> 1. This bug has always existed, so it's not a regression, so I'm not sure >> it's worth it to fix for 2.0 Sure, why not? >> 2. I'm not familiar with every detail of x86_cpu_get_phys_page_debug(), >> so I'm not completely sure this is the right thing to do >> >> target-i386/helper.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/target-i386/helper.c b/target-i386/helper.c >> index 4f447b8..9b7803f 100644 >> --- a/target-i386/helper.c >> +++ b/target-i386/helper.c >> @@ -951,6 +951,13 @@ hwaddr x86_cpu_get_phys_page_debug(CPUState *cs, vaddr addr) >> return -1; >> } >> >> + if (pdpe & PG_PSE_MASK) { >> + page_size = 1024 * 1024 * 1024; >> + pte = pdpe & ~( (page_size - 1) & ~0xfff); >> + pte &= ~(PG_NX_MASK | PG_HI_USER_MASK); >> + goto out; >> + } > > Does this also apply if we are not in long mode? No, it doesn't. The only valid bits in a PAE PDPTE are P, PWT and PCD. Bit 7 (PS) is reserved. Paolo