[Qemu-devel] qemu crashes and freezes on x86_64/amd64 host

[Qemu-devel] qemu crashes and freezes on x86_64/amd64 host

[Bob Deblier]

Current CVS version, statically compiled, running on FC2 x86_64 (a.k.a.
amd64)

Maybe these gdb sessions can help shed some light:

[bob@orion qemu]$ gdb qemu
GNU gdb Red Hat Linux (6.0post-0.20040223.19rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".

(gdb) set args -cdrom /opt/iso/w2k.iso -boot d w2k.img
(gdb) run
Starting program: /usr/bin/qemu -cdrom /opt/iso/w2k.iso -boot d w2k.img
 
Program received signal SIGSEGV, Segmentation fault.
tb_link_phys (tb=0xbd8dc8, phys_pc=33, phys_page2=426) at
/home/bob/emulators/cvs/qemu/exec.c:842
842         tb->page_next[n] = p->first_tb;
(gdb)

Another session crashes at the same location, with different values:

Program received signal SIGSEGV, Segmentation fault.
tb_link_phys (tb=0xbd8cf8, phys_pc=33, phys_page2=426) at
/home/bob/emulators/cvs/qemu/exec.c:842
842         tb->page_next[n] = p->first_tb;

Yet another possibility is that qemu apparently freezes; interrupting
gdb then gives:

(gdb) run
Starting program: /usr/bin/qemu -cdrom /opt/iso/w2k.iso -boot d w2k.img
 
Program received signal SIGINT, Interrupt.
0x000000000126cd4d in code_gen_buffer ()
(gdb) where
#0  0x000000000126cd4d in code_gen_buffer ()
#1  0x0000000001adbd00 in ?? ()
#2  0x0000000000446145 in cpu_x86_exec (env1=0xfd76) at
/home/bob/emulators/cvs/qemu/cpu-exec.c:545
#3  0x0000000000403294 in main_loop () at
/home/bob/emulators/cvs/qemu/vl.c:2463
#4  0x0000000000403fb3 in main (argc=64886, argv=0xc000) at
/home/bob/emulators/cvs/qemu/vl.c:3392
(gdb)

Any pointers welcome.

Sincerely,

Bob Deblier

Re: [Qemu-devel] qemu crashes and freezes on x86_64/amd64 host

[Karl Magdsick]

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.

Just a guess.


-Karl


On Thu, 07 Oct 2004 20:54:06 +0200, Bob Deblier <bob.deblier@telenet.be> wrote:
> Current CVS version, statically compiled, running on FC2 x86_64 (a.k.a.
> amd64)
> 
> Maybe these gdb sessions can help shed some light:
> 
> [bob@orion qemu]$ gdb qemu
> GNU gdb Red Hat Linux (6.0post-0.20040223.19rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
> libthread_db library "/lib64/tls/libthread_db.so.1".
> 
> (gdb) set args -cdrom /opt/iso/w2k.iso -boot d w2k.img
> (gdb) run
> Starting program: /usr/bin/qemu -cdrom /opt/iso/w2k.iso -boot d w2k.img
> 
> Program received signal SIGSEGV, Segmentation fault.
> tb_link_phys (tb=0xbd8dc8, phys_pc=33, phys_page2=426) at
> /home/bob/emulators/cvs/qemu/exec.c:842
> 842         tb->page_next[n] = p->first_tb;
> (gdb)
> 
> Another session crashes at the same location, with different values:
> 
> Program received signal SIGSEGV, Segmentation fault.
> tb_link_phys (tb=0xbd8cf8, phys_pc=33, phys_page2=426) at
> /home/bob/emulators/cvs/qemu/exec.c:842
> 842         tb->page_next[n] = p->first_tb;
> 
> Yet another possibility is that qemu apparently freezes; interrupting
> gdb then gives:
> 
> (gdb) run
> Starting program: /usr/bin/qemu -cdrom /opt/iso/w2k.iso -boot d w2k.img
> 
> Program received signal SIGINT, Interrupt.
> 0x000000000126cd4d in code_gen_buffer ()
> (gdb) where
> #0  0x000000000126cd4d in code_gen_buffer ()
> #1  0x0000000001adbd00 in ?? ()
> #2  0x0000000000446145 in cpu_x86_exec (env1=0xfd76) at
> /home/bob/emulators/cvs/qemu/cpu-exec.c:545
> #3  0x0000000000403294 in main_loop () at
> /home/bob/emulators/cvs/qemu/vl.c:2463
> #4  0x0000000000403fb3 in main (argc=64886, argv=0xc000) at
> /home/bob/emulators/cvs/qemu/vl.c:3392
> (gdb)
> 
> Any pointers welcome.
> 
> Sincerely,
> 
> Bob Deblier
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] qemu crashes and freezes on x86_64/amd64 host

[Bob Deblier]

On Sat, 2004-10-09 at 02:22, Karl Magdsick wrote:
> What is your compiler target when creating the qemu executible?

Native, i.e. x86_64-linux-gnu.

> 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.
> 
> Just a guess.

>From looking at the code, I don't get the impression that that's the
case. It may just be that some of the code isn't 64-bit clean, i.e. that
there are places where the coders have assumed that sizeof(pointer) = 4,
etc.

More investigating *sigh*

Bob

Re: [Qemu-devel] qemu crashes and freezes on x86_64/amd64 host

[Johannes Schindelin]

Hi,

On Sat, 9 Oct 2004, Bob Deblier wrote:

> From looking at the code, I don't get the impression that that's the
> case. It may just be that some of the code isn't 64-bit clean, i.e. that
> there are places where the coders have assumed that sizeof(pointer) = 4,
> etc.
>
> More investigating *sigh*

I don't know if that works, but what about valgrind? If QEmu can run
itself, valgrind should do a fine (if slow) job of detecting where a
pointer is passed incompletely... It would be slow, but also the lazy
way...

Hth,
Dscho

Re: [Qemu-devel] qemu crashes and freezes on x86_64/amd64 host

[Bob Deblier]

On Sat, 2004-10-09 at 12:08, Johannes Schindelin wrote:
> I don't know if that works, but what about valgrind? If QEmu can run
> itself, valgrind should do a fine (if slow) job of detecting where a
> pointer is passed incompletely... It would be slow, but also the lazy
> way...

Valgrind is x86 only - I'm running Fedora Core 2 x86_64 a.k.a. amd64
i.e. 64-bit native. I have no problems on Fedora Core 2 x86. 

Were you suggesting running qemu 32-bit in valgrind inside qemu 64-bit?
That wouldn't do much good, I'm afraid.

Bob

Re: [Qemu-devel] qemu crashes and freezes on x86_64/amd64 host

[Johannes Schindelin]

Hi,

On Sat, 9 Oct 2004, Bob Deblier wrote:

> Valgrind is x86 only - I'm running Fedora Core 2 x86_64 a.k.a. amd64
> i.e. 64-bit native. I have no problems on Fedora Core 2 x86.

Oops, sorry. I thought I read something about alpha x86_64 support in
valgrind, but I could not find it, so I guess it was PPC support.

Looking at your gdb session again, I would like to know: what is the value
of p? Is sizeof(unsigned int)==8? What is
sizeof(l1_map)/sizeof(PageDesc*)?

Ciao,
Dscho

Re: [Qemu-devel] qemu crashes and freezes on x86_64/amd64 host

[Bob Deblier]

On Sat, 2004-10-09 at 16:06, Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 9 Oct 2004, Bob Deblier wrote:
> 
> > Valgrind is x86 only - I'm running Fedora Core 2 x86_64 a.k.a. amd64
> > i.e. 64-bit native. I have no problems on Fedora Core 2 x86.
> 
> Oops, sorry. I thought I read something about alpha x86_64 support in
> valgrind, but I could not find it, so I guess it was PPC support.
> 
> Looking at your gdb session again, I would like to know: what is the value
> of p? Is sizeof(unsigned int)==8? What is
> sizeof(l1_map)/sizeof(PageDesc*)?

Unfortunately, gdb refuses to cough up the value of p:

Starting program: /usr/bin/qemu -cdrom /opt/iso/w2k.iso -boot d w2k.img
 
Program received signal SIGSEGV, Segmentation fault.
tb_link_phys (tb=0xbd1e10, phys_pc=33, phys_page2=426) at
/home/bob/emulators/cvs/qemu/exec.c:842
842         tb->page_next[n] = p->first_tb;
(gdb) list
837         PageDesc *p;
838         TranslationBlock *last_first_tb;
839
840         tb->page_addr[n] = page_addr;
841         p = page_find(page_addr >> TARGET_PAGE_BITS);
842         tb->page_next[n] = p->first_tb;
843         last_first_tb = p->first_tb;
844         p->first_tb = (TranslationBlock *)((long)tb | n);
845         invalidate_page_bitmap(p);
846
(gdb) print p
No symbol "p" in current context.

I assume it got "optimized away" because of compilation flag -O2; again,
unfortunately, the code refuses to compile without that flag. Tricky
stuff...

To answer your other question, according to gdb:
(gdb) print sizeof(unsigned int)
$1 = 4
(gdb) print sizeof(PageDesc*)
$2 = 8
(gdb) print sizeof(l1_map)
$3 = 8192
(gdb) print sizeof(l1_map) / sizeof(PageDesc*)
$4 = 1024

When compiling, there are many warnings about "cast from pointer to
integer of different size" and "cast to pointer from integer of
different size" which makes me highly suspicious about 64-bit
compatibility of the code.

Bob

[Qemu-devel] Re: qemu crashes and freezes on x86_64/amd64 host

[Andi Kleen]

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

[Qemu-devel] Re: qemu crashes and freezes on x86_64/amd64 host

[Karl Magdsick]

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

[Qemu-devel] Re: qemu crashes and freezes on x86_64/amd64 host

[Andi Kleen]

On Sat, Oct 09, 2004 at 02:31:05PM -0400, Karl Magdsick wrote:
> But my point is that if it's compiled for amd64, then the kernel will

Yep, you have to compile with -m32 

-Andi