From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVWBJ-0002kb-JR for qemu-devel@nongnu.org; Tue, 19 Aug 2008 14:43:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVWBG-0002jD-RA for qemu-devel@nongnu.org; Tue, 19 Aug 2008 14:43:49 -0400 Received: from [199.232.76.173] (port=43140 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVWBG-0002j0-Fc for qemu-devel@nongnu.org; Tue, 19 Aug 2008 14:43:46 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]:59160) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVWBF-0001gZ-SK for qemu-devel@nongnu.org; Tue, 19 Aug 2008 14:43:46 -0400 Received: by wr-out-0506.google.com with SMTP id c46so114282wra.18 for ; Tue, 19 Aug 2008 11:43:42 -0700 (PDT) Message-ID: <48AB1434.9070803@codemonkey.ws> Date: Tue, 19 Aug 2008 13:43:00 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Bug with TARGET_PHYS_ADDR_SPACE_BITS References: <48AB070A.1040104@redhat.com> In-Reply-To: <48AB070A.1040104@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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. Regards, Anthony Liguori > Thanks, > Chris Lalancette > > >