From: Karl Magdsick <kmagnum@gmail.com>
To: Andi Kleen <ak@muc.de>, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: qemu crashes and freezes on x86_64/amd64 host
Date: Sat, 9 Oct 2004 14:31:05 -0400 [thread overview]
Message-ID: <cd8ecdef04100911314cbf6a6c@mail.gmail.com> (raw)
In-Reply-To: <m3vfdjyicm.fsf@averell.firstfloor.org>
But my point is that if it's compiled for amd64, then the kernel will
see in the ELF header that it is 64-bit code and will not switch to
32-bit compat mode for that process's threads. Unless someone has
re-written the dynamic code generator to generate amd64 code, then the
dynamic code generator is generating 32-bit code that's then being
executed in non-32-bit-compat mode, due to the rest of the code being
64-bit code.
It's like linking 64-bit object code and 32-bit object code into the
same executible. It may very well be the case that the rest of the
code isn't completely 64-bit clean. However, I believe there is a
fundamental problem in calling 32-bit code from 64-bit code without
switching into 32-bit-compat mode (which I would guess is a privledged
instruction).
Under Linux, if you are willing to use raw clone system calls instead
of libpthread, you may be able to create a 32-bit compat thread whose
entire address space is a subset of your 64-bit address space and you
may be able to keep that 32-bit thread inside the dynamically
generated code (maybe having the 32-bit thread set a pointer for its
next jump and then wait on a mutex or semaphore while the 64-bit
threads create the 32-bit code corresponding to that pointer).
However, it would be much easier to just modify the x86 dynamic code
generator to emit amd64 code.
-Karl
On Sat, 09 Oct 2004 18:19:37 +0200, Andi Kleen <ak@muc.de> wrote:
> Karl Magdsick <kmagnum@gmail.com> writes:
>
> > What is your compiler target when creating the qemu executible?
> >
> > My understanding is that almost all of the instructions in 64-bit mode
> > are reverse-compatible with 32-bit mode, but a few have changed
> > slightly. If your qemu executible is compiled for 64-bit mode (and is
> > therefore being run in 64-bit usermode), but the jit is generating
> > 32-bit code, this could be problematic for a small number of
> > instructions. I have no direct knowledge of the differences between
> > the instruction encodings for 32-bit and 64-bit modes, just hearsay.
>
> That's basically correct, but x86-64 has a "compat mode" that executes
> old 32bit programs without changes. When qemu has been compiled
> as 32bit program it will run in compat mode.
>
> The main reason things crash there is that it gives these programs
> by default 4GB of address space. An i386 kernel defaults to 3GB.
> You can force the 3GB address space with linux32 --3gb ...
>
> I tested an older 32bit qemu version and it worked for me on an 64bit
> kernel. Wasn't able to compile a new one so far because someone
> added a bogus dependency on arts.
>
> -Andi
>
>
next prev parent reply other threads:[~2004-10-09 18:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 18:54 [Qemu-devel] qemu crashes and freezes on x86_64/amd64 host Bob Deblier
2004-10-09 0:22 ` Karl Magdsick
2004-10-09 5:29 ` Bob Deblier
2004-10-09 10:08 ` Johannes Schindelin
2004-10-09 12:03 ` Bob Deblier
2004-10-09 14:06 ` Johannes Schindelin
2004-10-09 15:28 ` Bob Deblier
2004-10-09 16:19 ` [Qemu-devel] " Andi Kleen
2004-10-09 18:31 ` Karl Magdsick [this message]
2004-10-09 18:38 ` Andi Kleen
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=cd8ecdef04100911314cbf6a6c@mail.gmail.com \
--to=kmagnum@gmail.com \
--cc=ak@muc.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).