Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
Hi
2007/4/17, Atif Hashmi [EMAIL PROTECTED]:
But this prints Transaction restart once and then the program finishes.
This means that commit transaction is not called the second time. Could you
please tell me what am I doing wrong?
Helper functions are outside the translated opcode stream and are invoked by
call/ret:
.--.
| |
| ---+-- helper_StartTransaction()
| --+---/
| |
| |
| ---+-- helper_CommitTransaction()
| --+---/
| |
'--'
When you longjmp from helper_CommitTransaction to helper_StartTransaction
it's probable that you return back to the point where
helper_CommitTransaction should have returned to, as it is the last address
stored in the stack.
Anyway, guest code between the start and the end of the transaction should
not be rerun without updating guest machine state (eip, flags, etc.).
You should better forget about using setjmp/longjmp. Maybe something like
this could do the trick:
when translating mov %al,%al:
{
...
...
store the address (eip) of mov %al,%al instruction somewhere
gen_op_start_transaction();
}
when translating mov %bl, %bl:
{
...
...
gen_op_commit_transaction(stored_eip);
gen_eob(s); // Stop translation to force guest state updating
}
op_commit_transaction should look like:
{
if ( helper_CommitTransaction() ) // helper should return !=0 on error
EIP = PARAM1;
}
Regards,
Eduardo
Re: [Qemu-devel] Simtec BAST emulation
On Mon, 2007-04-02 at 18:45 +0100, Paul Brook wrote: A few issues with the patch, which I think need to be resolved before it can be applied: - You're using global structures to store machine state. While it's debatable whether you'll ever have more than one s3c2410, I think it's definitely still worth allowing for this possibility, and encapsulating the state in a structure, like all the other hardware emulation does. Yes, I concur, this is my next goal. - For the device emulation (dm9000 and ide, maybe others) you should use pic_set_irq_new, instead of passing a separate set_irq function. Other ARM boards already support arbitrary routing of interrupts via hw/arm_pic.[ch]. pic_set_irq_new appears to be missing from trunk unless I'm mistaken or confused. However hw/irq.[ch] seemed like a nice place to start, so I've made the s3c2410x_irq stuff use that, and ported all the other drivers we wrote to this. It has unfortunately added more global state for the s3c2410x which I will work on factoring into a new structure next. - usb_ohci_mmap_init should look more like (or even be the same function as) usb_ohci_init_pxa. I am now using usb_ohci_init_pxa for this. What is the licence for ABLE? Would we be able to distribute it with qemu? ABLE is not going to be distributable *with* qemu, however it may be possible to ensure that the licence is such that anyone wishing to use ABLE with qemu will be allowed to in a free-beer sense by downloading it from Simtec's website. Would you mind casting your eye over the attached diff and tell me if I went the right way with the IRQ stuff? I'll get on with deglobalising (localising?) the s3c2410x state next. D. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
Re: [Qemu-devel] sizeof(target_int)
Kirill A. Shutemov wrote:
Is it possible to get size of target int? Why is only TARGET_LONG_BITS
defined?
I have need of size of target int for correct define fsid_t for linux user
mode. fsid_t is struct { int val[2]; } for linux.
That's int32_t for all Linux versions and architectures.
Thiemo
Re: [Qemu-devel] time inside qemu
code (a) : for (int i = 0; i 100; i++) c[i] = a[i] * b[i]; code (b) : for (int i = 0; i 1000; i++) for(int j = 0; j b[i]; j++) c[i] += a[i]; code (c) : for (int i = 0; i 1000; i++) c[i] = HW_MUL(a[i], b[i]); I'm sure that code (b) will execute much longer that code (a) inside qemu (sure that different that in real platform), and I'd like to compute executing time for code (c) in some way. So, how can I trap time information/calculation inside qemu? You can't. As I've said before, any performance measurements you make inside qemu are completely meaningless. You may be able to say that executing 1000 iterations takes longer than 10 iterations of the same loop, but you didn't need a simulator to tell you that. Also, there's a good chance qemu will take almost exactly the same time to execute them because the execution time will be dominated by the translation time for the first iteration. You can not compare the cost of (say) add v.s. multiply, or of two different multiply instructions. The timings for the individual instructions (or any particular sequence of instructions) bear no relation whatsoever to the timings for the same sequence on real hardware. I'm repeating myself now, so I intend this to my my last response to this thread. Paul
[Qemu-devel] qemu hw/mips_timer.c target-mips/cpu.h target-m...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/17 15:26:47 Modified files: hw : mips_timer.c target-mips: cpu.h mips-defs.h op.c op_helper.c translate.c translate_init.c Log message: Choose number of TLBs at runtime, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_timer.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemur1=1.29r2=1.30 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemur1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.43r2=1.44 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.41r2=1.42 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.65r2=1.66 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemur1=1.5r2=1.6
[Qemu-devel] qemu vl.h hw/mc146818rtc.c hw/mips_pica61.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/17 16:28:29 Modified files: . : vl.h hw : mc146818rtc.c mips_pica61.c Log message: Fix mmapped register alignment and endianness handling. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.215r2=1.216 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mc146818rtc.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemur1=1.1r2=1.2
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
On Mon, Apr 16, 2007 at 08:47:07AM +0200, Werner Dittmann wrote: My general thought about the problem: running 32bit code on a 64bit host with similar architecture as this is the case of x86 / x86_64 could easily result in problems with signedness, sign bit extension, different pointer/word/interger sizes... qemu-system-x86_64 has indeed some signedness problem. I posted a patch [EMAIL PROTECTED] a couple of days ago for the problem that the pagefault address gets incorrectly sign extended when running 32-bit code. Nevertheless its just a workaround, the place where this wrong sign extension happend needs still to be found. Bernhard Kauer
Re: [Qemu-devel] [PATCH] ARM XScale core features and PXA270 and PXA255 emulation.
Hi, On 17/04/07, Christian MICHON [EMAIL PROTECTED] wrote: On 3/16/07, andrzej zaborowski [EMAIL PROTECTED] wrote: Implements basic differences between XScale and plain ARM. The patch also adds the main on-chip peripherals of PXA2xx: interrupt controller, DMA, GPIO controller, SSP, I2C, I2S busses, UARTs, FIR port, RTC, Clock/Power/Memory managers. Cheers, Andrew interesting (I haven't tested it yet)... how to use this patch ? beside the -portrait extra switch, applying this patch would make arm-softmmu a pxa2xx by default ? No, default is whatever the machine uses (-M). Use this patch together with the rest of the series. if so, it's very interesting: I've an ipaq (H2210) and I was taking part of a port of linux on it. One big drawback then is that I burned a few SD cards to get a kernel working, but this patch could be a good fix to my problems... Do I just need the 2 emails with pxa2xx patches ? or is there more needed ? For PXA you need only the two patches. But PXA is only a processor and the processor alone is useless. Last, but not least: do you think we could emulate a windows CE pocketpc in this way ? See http://lists.gnu.org/archive/html/qemu-devel/2007-02/msg00109.html Regards, Andrew
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
andrzej zaborowski wrote: Hi, On 16/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: During several tests with Qemu / Kqemu it seems that Qemu has problems with x86_64 host systems. My system is an AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. Indeed it is a dual CPU. Adding notsc as an additional parameter to the kernel commandline (the guest system uses Lilo). Using this parameter the kernel was able to start INIT and the init.d startup scripts (not always, but most of the time). After a short time the kernel starts to loop again, e.g. during hotplug handling. Using th same technique as before (gdb) it's the same picture: mainly in compute_c_subl or compute_c_addl. Does your host happen to be dual-core? If so, please try adding notsc to the guest kernel commandline and report if it makes a difference. I thought qemu's gdb server is used to debug kernels running inside Qemu but not to debug Qemu itself. IMHO the problem is not in the kernel (the kernel works perfectly on a real HW processor) but in Qemu. Use qemu's gdb server, it's documented. Regards, Andrzej Regards, Werner
[Qemu-devel] qemu-multi-configs.diff
Hi there There should exist a patch to get more than one usb device in Qemu, but all the links I can find are broken :( Could you guys help with that? Best regards Kim Højgaard-Hansen
[Qemu-devel] qemu/hw tcx.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/04/17 19:42:21 Modified files: hw : tcx.c Log message: TCX palette bug fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tcx.c?cvsroot=qemur1=1.11r2=1.12
Re: [Qemu-devel] Qemu / KQemu on 64-bit (x86_64) host systems
Hi, On 17/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: andrzej zaborowski wrote: Hi, On 16/04/07, Werner Dittmann [EMAIL PROTECTED] wrote: During several tests with Qemu / Kqemu it seems that Qemu has problems with x86_64 host systems. My system is an AMD 64 X2 (Dual Core), running openSUSE 10.2, 2GB memory. Indeed it is a dual CPU. Adding notsc as an additional parameter to the kernel commandline (the guest system uses Lilo). Using this parameter the kernel was able to start INIT and the init.d startup scripts (not always, but most of the time). After a short time the kernel starts to loop again, e.g. during hotplug handling. Hmm, I was thinking that it may be the same problem as I described in http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html but if the lockup is happening anyway then I'm not sure. On the other hand notsc does make a difference, right? Using th same technique as before (gdb) it's the same picture: mainly in compute_c_subl or compute_c_addl. Does your host happen to be dual-core? If so, please try adding notsc to the guest kernel commandline and report if it makes a difference. I thought qemu's gdb server is used to debug kernels running inside Qemu but not to debug Qemu itself. IMHO the problem is not in the kernel (the kernel works perfectly on a real HW processor) but in Qemu. That's right, qemu's gdb server is for debugging the guest. However, it's often much easier to debug qemu knowing what guest code is causing the qemu bug, especially C code in case of opensource guests, and especially a guest lockup or guest crash. Other than that I think there's only the -d. Regards, Andrzej
[Qemu-devel] [PATCH] PPC termios structure ordering
Just found a small problem w/ the termios structure as defined for PPC linux user. It doesn't match the one in include/asm-powerpc/termbits.h. Index: linux-user/ppc/termbits.h === --- linux-user/ppc/termbits.h (revision 44) +++ linux-user/ppc/termbits.h (working copy) @@ -7,8 +7,8 @@ unsigned int c_oflag; /* output mode flags */ unsigned int c_cflag; /* control mode flags */ unsigned int c_lflag; /* local mode flags */ +unsigned char c_cc[TARGET_NCCS];/* control characters */ unsigned char c_line;/* line discipline */ -unsigned char c_cc[TARGET_NCCS];/* control characters */ unsigned int c_ispeed; /* input speed */ unsigned int c_ospeed; /* output speed */ }; With this change, both host and target 'stty -a' give the same output. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
Re: [Qemu-devel] Re: Detecting an assembly instruction in QEMU
HI Eduardo,
Thanks for you reply. I have update target-i386/translate.c as follows
if(modrm==0xC0)
{
stored_eip = pc_start - s-cs_base;
gen_op_movl_AL_AL();
}
else if(modrm==0xDB)
{
gen_op_movl_BL_BL(stored_eip);
gen_eob(s);
}
target-i386/op.c contains the following.
void OPPROTO op_movl_AL_AL()
{
helper_StartTransaction();
}
void OPPROTO op_movl_BL_BL()
{
if(helper_CommitTransaction())
{
EIP = PARAM1;
}
}
and helper.c looks like
void helper_StartTransaction()
{
printf(StartTransaction Called\n);
}
unsigned char helper_CommitTransaction()
{
static int i=0;
printf(CommitTransaction Called\n);
return 1;
}
Essentially, if we have a program like
int main()
{
__asm_volatile(mov %al %al); //is detected in translation.c and
helper_StartTransaction is called
printf(middle);
__asm_volatile(mov %bl %bl); //is detected in translation.c and
helper_CommitTransaction is called
}
We should continuously print middle on the QEMU screen while
StartTransaction Called and End Transaction Called for infinite amount
of time.
But I get the following behaviour.
On QEMU screen, middle is printed once, and I get the following on the
xterm
StartTransaction Called
CommitTransaction Called
StartTransaction Called
After that I get the QEMU prompt back and the program finishes. I still have
not been able to figure it out why after calling helper_StartTransaction()
for the seconds time the program does not continue? Is their anything else
that we have not considered.
I will really appreciate your help.
Regards,
Atif
On 4/17/07, Eduardo Felipe [EMAIL PROTECTED] wrote:
Hi
2007/4/17, Atif Hashmi [EMAIL PROTECTED]:
But this prints Transaction restart once and then the program
finishes. This means that commit transaction is not called the second time.
Could you please tell me what am I doing wrong?
Helper functions are outside the translated opcode stream and are invoked
by call/ret:
.--.
| |
| ---+-- helper_StartTransaction()
| --+---/
| |
| |
| ---+-- helper_CommitTransaction()
| --+---/
| |
'--'
When you longjmp from helper_CommitTransaction to helper_StartTransaction
it's probable that you return back to the point where
helper_CommitTransaction should have returned to, as it is the last address
stored in the stack.
Anyway, guest code between the start and the end of the transaction should
not be rerun without updating guest machine state (eip, flags, etc.).
You should better forget about using setjmp/longjmp. Maybe something like
this could do the trick:
when translating mov %al,%al:
{
...
...
store the address (eip) of mov %al,%al instruction somewhere
gen_op_start_transaction();
}
when translating mov %bl, %bl:
{
...
...
gen_op_commit_transaction(stored_eip);
gen_eob(s); // Stop translation to force guest state updating
}
op_commit_transaction should look like:
{
if ( helper_CommitTransaction() ) // helper should return !=0 on error
EIP = PARAM1;
}
Regards,
Eduardo
Re: [Qemu-devel] linux-user target
On Tue, 10 Apr 2007, Jocelyn Mayer wrote: PPC: I am unable to get any executable to run. projects:~/upstream/qemu# ./ppc-linux-user/qemu-ppc -L /mirror0/chroots/ppc/ /mirror0/chroots/ppc/bin/bash init_ppc_proc: PVR 0008 mask = 0008 Segmentation fault projects:~/upstream/qemu# Just checked, on an amd64 host with a random powerpc bash version I got on my hard disk drive: ./ppc-linux-user/qemu-ppc -L /mnt/local/hdc/part3/PPC/linux/archives /mnt/local/hdc/part3/PPC/linux/archives/bin/bash --version init_ppc_proc: PVR 0008 mask = 0008 GNU bash, version 2.05a.0(1)-release (powerpc-unknown-linux-gnu) Copyright 2001 Free Software Foundation, Inc. I also tried to really launch the shell and use it and it worked. ... I have to admit there are some strange behaviors with some features... But I think recent builds using glibc with TLS/NPTL would not run. I've continued to work on this all week, and I still haven't managed to solve it. I've chased down a lot of paths, but none of them have lead to a solution. Here is a summary of the situation now. * programs other than bash will run * bash --version will run * bash --noediting will run * occasionally, bash has run if I'm stracing it, but I can't always reproduce it. * when it runs, I occasionally see some odd behavior, but not always. The termios patch I just sent cleared up a lot of the oddness. * when it runs, it hangs on exit. Killing it logs me all the way out of the system (ssh conection). * when it crashes, gdb looses the user level thread, so I can't do any debugging * I don't see any of the TLS related system calls being called. I also don't see any concrete proof one way or another that it is used in the executable (ie No R_PPC_*TLS relocations). I've been digging in the kernel glibc source, and I don't see a lot of special code to support TLS on ppc. It mostly seems to be just taking care to not step on R2. Glibc seems to be the only place where it knows something specific about TLS, which leads me to think that TLS is mostly contain within the userspace on PPC. * I've tried turning on most of the DEBUG_ defines under linux-user, but none of them has yielded anything useful, or noteworthy. Whew.. I'm in need a of a fresh idea or three. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
[Qemu-devel] qemu/fpu softfloat-native.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/17 21:57:02 Modified files: fpu: softfloat-native.h Log message: Updated Solaris isinf support, by Juergen Keil and Ben Taylor. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat-native.h?cvsroot=qemur1=1.9r2=1.10
Re: [Qemu-devel] 16-bit (and 8-bit) emulation
[EMAIL PROTECTED]/p1 ~/src/c/todd/test?100$ ./sizeof sizeof(char) = 1 sizeof(short) = 2 sizeof(int) = 4 sizeof(char *) = 4 sizeof(long) = 4 sizeof(long long) = 8 [EMAIL PROTECTED]/p1 ~/src/c/todd/test?101$ uname -a OpenBSD cloud.fries.net 4.1 GENERIC#7 mac68k [EMAIL PROTECTED]/p1 ~/src/c/todd/test?102$ FWIW. -- Todd Fries .. [EMAIL PROTECTED] _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | ..in support of free software solutions. \ 250797 (FWD) | \ \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt Penned by Nigel Horne on 20070415 13:08.57, we have: | Stuart Brady wrote: | On Sun, Apr 15, 2007 at 11:08:56AM +0100, Nigel Horne wrote: | Can qemu emulate 16-bit machines (286?)? | | None that I'm aware of. Is there any particular need for 286 emulation? | | To test my code on machines where sizeof(int) == sizeof(short), and | sizeof(int) != sizeof(long). | | OTOH, it might be interesting to see some m68k system emulation. | | I can't remember now what sizeof(int) and sizeof(char *) were on m68k | machines. | | -Nigel | | -- | Nigel Horne. Arranger, Adjudicator, Band Trainer, Composer, Tutor, | Typesetter. | NJH Music, Barnsley, UK. ICQ#20252325 | [EMAIL PROTECTED] http://www.bandsman.co.uk | begin:vcard | fn:Nigel Horne | n:Horne;Nigel | org:NJH Music | email;internet:[EMAIL PROTECTED] | tel;fax:+44 870 705 9334 | note:Skype: nigelhorne | x-mozilla-html:FALSE | version:2.1 | end:vcard |
[Qemu-devel] qemu/target-i386 helper2.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/17 23:08:56 Modified files: target-i386: helper2.c Log message: Ptable calculation broken for 32bit code under x86_64, by Bernhard Kauer. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemur1=1.46r2=1.47
Re: [Qemu-devel] 0.9.0 Win32 Tap inferface PPC Guest issue
Ely Soto wrote: Ok this is the fix I came up with. Basically it will check all the other objects that could potentially be waiting for service. This will prevent one high priority object from starving the rest. I'm not certain what the intention for the timeout 0 check but this completely prevented any wait object servicing on my machine. The Tap interface now works smoothly without issue. Please resend the version for current CVS as unified diff (diff -u) without breaking the line formatting (an attachment should do). Thiemo
[Qemu-devel] qemu/target-i386 helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/17 23:25:07 Modified files: target-i386: helper.c Log message: Fix helper.c with isinf on Solaris 9/Sparc, by Ben Taylor. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemur1=1.78r2=1.79
[Qemu-devel] qemu/hw lsi53c895a.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/04/17 23:53:10 Modified files: hw : lsi53c895a.c Log message: Another lsi53c895a patch, by Wang Cheng Yeh. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/lsi53c895a.c?cvsroot=qemur1=1.6r2=1.7
