All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Bug with TARGET_PHYS_ADDR_SPACE_BITS
Date: Tue, 19 Aug 2008 13:43:00 -0500	[thread overview]
Message-ID: <48AB1434.9070803@codemonkey.ws> (raw)
In-Reply-To: <48AB070A.1040104@redhat.com>

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
>
>
>   

  reply	other threads:[~2008-08-19 18:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-19 17:46 [Qemu-devel] Bug with TARGET_PHYS_ADDR_SPACE_BITS Chris Lalancette
2008-08-19 18:43 ` Anthony Liguori [this message]
2008-08-19 19:06   ` Blue Swirl
2008-08-20  9:10   ` Alan Pevec
2008-08-20  6:15 ` Aurelien Jarno
2008-08-21 14:47   ` Chris Lalancette
2008-09-07  2:16     ` Anthony Liguori
2008-09-08  7:09       ` Chris Lalancette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48AB1434.9070803@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.