From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVWXf-00082k-F1 for qemu-devel@nongnu.org; Tue, 19 Aug 2008 15:06:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVWXe-00082M-MR for qemu-devel@nongnu.org; Tue, 19 Aug 2008 15:06:54 -0400 Received: from [199.232.76.173] (port=50691 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVWXe-00082J-GS for qemu-devel@nongnu.org; Tue, 19 Aug 2008 15:06:54 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:52606) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVWXe-0006il-2n for qemu-devel@nongnu.org; Tue, 19 Aug 2008 15:06:54 -0400 Received: by gxk12 with SMTP id 12so5216232gxk.10 for ; Tue, 19 Aug 2008 12:06:53 -0700 (PDT) Message-ID: Date: Tue, 19 Aug 2008 22:06:52 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] Bug with TARGET_PHYS_ADDR_SPACE_BITS In-Reply-To: <48AB1434.9070803@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48AB070A.1040104@redhat.com> <48AB1434.9070803@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 8/19/08, Anthony Liguori wrote: > Chris Lalancette wrote: > > > Hello, > > oVirt is currently using straight x86_64 qemu emulation for certain > parts > > of the architecture (we mostly use KVM, but need to use full emulation for > a > > couple of parts). We recently upgraded our userspace package to kvm-72, > but > > found that we could not PXE boot guests when we were doing full emulation > (under > > kvm, we could PXE boot just fine). We also tried using qemu SVN tip, with > > similar results. We ended up doing a bisect, and tracked down the problem > to > > this commit (from the kvm repo, but pulled from qemu): > > > > > http://git.kernel.org/?p=linux/kernel/git/amit/kvm-userspace.git;a=commit;h=468f7507339a5236bff8ab339eb0c1b019a95fda > > > > The important changes in there in terms of this bug revolves around > > TARGET_PHYS_ADDR_SPACE_BITS in exec.c. If I change that back to 32 (what > it was > > before this patch for x86_64), the PXE boot succeeds. Also, if I remove > > TARGET_PHYS_ADDR_SPACE_BITS > 32 conditional code in > phys_page_find_alloc(), but > > leave TARGET_PHYS_ADDR_SPACE_BITS as 42, the PXE boot also works. I can't > claim > > to understand the conditional code I've compiled out, so I'm not sure > where the > > bug would be. Does anyone have an idea what the problem might be? > > > > > > Right now, the code just can't handle TARGET_PHYS_ADDR_SPACES_BITS > 32. > This may help you: > > diff --git a/exec.c b/exec.c > index a0aa7dc..cac7a87 100644 > --- a/exec.c > +++ b/exec.c > @@ -153,7 +153,7 @@ typedef struct PhysPageDesc { > */ > #define L1_BITS (TARGET_VIRT_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS) > #else > -#define L1_BITS (32 - L2_BITS - TARGET_PAGE_BITS) > +#define L1_BITS (TARGET_PHYS_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS) > #endif > > #define L1_SIZE (1 << L1_BITS) > > But there are a lot more places in the code that assume > TARGET_PHYS_ADDR_SPACE_BITS == 32. I'm inclined to think that we should > change it back to 32. Sparc32 uses 36 bits successfully, on SS-10/20/600MP a lot of devices are located near the top of physical address space. Sparc64 boots using address 0x1ff f000 0020 and that uses 42 bits (top bit zero). I think I have found a bug...