[Qemu-devel] [PATCH] 4/5: Adjustment needed for (some?) amd64 guests on i386 hosts

[Qemu-devel] [PATCH] 4/5: Adjustment needed for (some?) amd64 guests on i386 hosts

[Juergen Lock]

Index: qemu/exec-all.h
@@ -30,7 +30,7 @@
 struct TranslationBlock;
 
 /* XXX: make safe guess about sizes */
-#define MAX_OP_PER_INSTR 64
+#define MAX_OP_PER_INSTR 128 /* 64 */
 /* A Call op needs up to 6 + 2N parameters (N = number of arguments).  */
 #define MAX_OPC_PARAM 10
 #define OPC_BUF_SIZE 512

Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>

Re: [Qemu-devel] [PATCH] 4/5: Adjustment needed for (some?) amd64 guests on i386 hosts

[Thiemo Seufer]

Juergen Lock wrote:
> Index: qemu/exec-all.h
> @@ -30,7 +30,7 @@
>  struct TranslationBlock;
>  
>  /* XXX: make safe guess about sizes */
> -#define MAX_OP_PER_INSTR 64
> +#define MAX_OP_PER_INSTR 128 /* 64 */

Is this still needed? AFAIR a similiar problem was fixed a while ago.


Thiemo

[Qemu-devel] Documentation/tools on debuging dyngen code?

[Bruce Beare (bbeare)]

I'm working on a 2.6.24 Linux port built for ARCH=powerpc and configured
for the PReP machine. I have the port booting using an unmodified 0.9.1
version (actually, head from the SVN repo) of qemu-system-ppc but
sometimes find that QEMU "hangs". Analysis of the hang reveals:

  o C-A C-X does not respond
  o QEMU is sucking up 100% cpu time of one processor
  o GDB to the kernel debug port (qemu option -s -p 1234) is non
responsive
  o ltrace, strace show no system or library calls in progress
  o GDB on QEMU shows that it is executing apparently valid code in the
0x4xxxxxxx
    range.

My conclusion is that QEMU is looping while executing the dynamically
generated code. I'd like to debug this further... and am looking for
some pointers on how to do so. Is there a built-in debugger? Is there a
particular probe point that I should set a GDB breakpoint on? What is
the general procedure for doing this level of debug?

Thanks for any help...
Bruce


bbeare@bbeare-lnx:/nobackup/bbeare/ppcroot$ pstack 21406
#0  0x0000000041c1bc23 in ?? ()
#1  0x0000000000000007 in ?? ()
#2  0x0000000000000000 in ?? ()
bbeare@bbeare-lnx:/nobackup/bbeare/ppcroot$ pstack 21406
#0  0x0000000041c1bc81 in ?? ()
#1  0x0000000000000000 in ?? ()
bbeare@bbeare-lnx:/nobackup/bbeare/ppcroot$ pstack 21406
#0  0x0000000041c1bc23 in ?? ()
#1  0x0000000000000007 in ?? ()
#2  0x0000000000000000 in ?? ()
bbeare@bbeare-lnx:/nobackup/bbeare/ppcroot$ pstack 21406
#0  0x0000000041c1bc30 in ?? ()
#1  0x0000000000000000 in ?? ()
bbeare@bbeare-lnx:/nobackup/bbeare/ppcroot$ pstack 21406
#0  0x0000000041c1bb6f in ?? ()
#1  0x0000000000000000 in ?? ()
bbeare@bbeare-lnx:/nobackup/bbeare/ppcroot$ pstack 21406
#0  0x0000000041c1bb71 in ?? ()
#1  0x0000000000000000 in ?? ()
bbeare@bbeare-lnx:/nobackup/bbeare/ppcroot$ pstack 21406
#0  0x0000000041c1bbf2 in ?? ()
#1  0x0000000000000007 in ?? ()
#2  0x0000000000000000 in ?? ()
bbeare@bbeare-lnx:/nobackup/bbeare/ppcroot$ pstack 21406
#0  0x0000000041c1bb53 in ?? ()
#1  0x0000000000000000 in ?? ()

Re: [Qemu-devel] Documentation/tools on debuging dyngen code?

[Mulyadi Santosa]

On 10/2/08, Bruce Beare (bbeare) <bbeare@cisco.com> wrote:
> I'm working on a 2.6.24 Linux port built for ARCH=powerpc and configured
> for the PReP machine. I have the port booting using an unmodified 0.9.1
> version (actually, head from the SVN repo) of qemu-system-ppc but
> sometimes find that QEMU "hangs". Analysis of the hang reveals:
>
>   o C-A C-X does not respond
>   o QEMU is sucking up 100% cpu time of one processor
>   o GDB to the kernel debug port (qemu option -s -p 1234) is non
> responsive
>   o ltrace, strace show no system or library calls in progress
>   o GDB on QEMU shows that it is executing apparently valid code in the
> 0x4xxxxxxx
>     range.
>
> My conclusion is that QEMU is looping while executing the dynamically
> generated code. I'd like to debug this further... and am looking for
> some pointers on how to do so. Is there a built-in debugger? Is there a
> particular probe point that I should set a GDB breakpoint on? What is
> the general procedure for doing this level of debug?

I suggest to observe the generated code first. Explore the -d option
of qemu. For complete list of what you can log, use "qemu -d ?".

regards,

Mulyadi

Re: [Qemu-devel] [PATCH] 4/5: Adjustment needed for (some?) amd64 guests on i386 hosts

[Juergen Lock]

On Wed, Oct 01, 2008 at 10:20:09PM +0200, Thiemo Seufer wrote:
> Juergen Lock wrote:
> > Index: qemu/exec-all.h
> > @@ -30,7 +30,7 @@
> >  struct TranslationBlock;
> >  
> >  /* XXX: make safe guess about sizes */
> > -#define MAX_OP_PER_INSTR 64
> > +#define MAX_OP_PER_INSTR 128 /* 64 */
> 
> Is this still needed? AFAIR a similiar problem was fixed a while ago.

Still needed.  Tested with FreeBSD 7.0-RELEASE-amd64-livefs.iso, qemu
still crashes in the old way without this patch.

 Regards,
	Juergen

Re: [Qemu-devel] Documentation/tools on debuging dyngen code?

[andrzej zaborowski]

2008/10/1 Bruce Beare (bbeare) <bbeare@cisco.com>:
> I'm working on a 2.6.24 Linux port built for ARCH=powerpc and configured
> for the PReP machine. I have the port booting using an unmodified 0.9.1
> version (actually, head from the SVN repo) of qemu-system-ppc but
> sometimes find that QEMU "hangs". Analysis of the hang reveals:
>
>  o C-A C-X does not respond
>  o QEMU is sucking up 100% cpu time of one processor
>  o GDB to the kernel debug port (qemu option -s -p 1234) is non
> responsive
>  o ltrace, strace show no system or library calls in progress
>  o GDB on QEMU shows that it is executing apparently valid code in the
> 0x4xxxxxxx
>    range.
>
> My conclusion is that QEMU is looping while executing the dynamically
> generated code. I'd like to debug this further... and am looking for
> some pointers on how to do so. Is there a built-in debugger? Is there a

I'm seeing a similar lock-up since around the time of the conversion
to TCG.  It's caused by an interrupt being lost for some reason (a
signal not causing an exit from cpu loop properly).  I've hit it on an
ARM target and Daniel Jacobowitz reproduced it on an x86 target).  If
what you see is the same problem, adding -clock unix manages to work
around it because it means that signals will keep coming even if one
is lost and eventually the cpu loop will end, but this isn't a proper
fix.

Cheers