From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CGM6z-0004FI-Ly for qemu-devel@nongnu.org; Sat, 09 Oct 2004 14:38:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CGM6z-0004Ey-30 for qemu-devel@nongnu.org; Sat, 09 Oct 2004 14:38:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CGM6y-0004Eo-Uk for qemu-devel@nongnu.org; Sat, 09 Oct 2004 14:38:32 -0400 Received: from [64.233.170.201] (helo=mproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CGLzq-0005NA-KA for qemu-devel@nongnu.org; Sat, 09 Oct 2004 14:31:10 -0400 Received: by mproxy.gmail.com with SMTP id 73so260828rnl for ; Sat, 09 Oct 2004 11:31:05 -0700 (PDT) Message-ID: Date: Sat, 9 Oct 2004 14:31:05 -0400 From: Karl Magdsick In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1097175246.2833.51.camel@orion> Subject: [Qemu-devel] Re: qemu crashes and freezes on x86_64/amd64 host Reply-To: Karl Magdsick , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andi Kleen , qemu-devel@nongnu.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 wrote: > Karl Magdsick 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 > >