[Qemu-devel] [PATCH, MIPS] Code translation improvement
Hi,
The patch below makes a few improvement to the code translation, and fixes
a small bug:
- The check for the bit ERL in CP0 Status register implies that the CPU
is in kernel mode, so there is no need to further check for user mode.
- Checking for the bit UM in CP0 Status register is not enough to detect
the user mode, the patch below changes that to a check for
MIPS_HFLAG_UM in hflags.
- Currently checking if CP0 is accessible, ie either the CPU is in kernel
mode or the bit CU0 in CP0 Status register enabled, is done in the
translated code. The patch below moves the check for user mode at
translation time to improve a bit the execution time. It also saves a
call to save_cpu_state() if the CPU is in kernel mode. A few CP0
instructions then needs to explicitely save the cpu state, as they
are modifying hflags.
Cheers,
Aurelien
Index: target-mips/helper.c
===
RCS file: /sources/qemu/qemu/target-mips/helper.c,v
retrieving revision 1.42
diff -u -d -p -r1.42 helper.c
--- target-mips/helper.c28 May 2007 20:36:48 - 1.42
+++ target-mips/helper.c14 Jun 2007 19:32:56 -
@@ -130,7 +130,7 @@ static int get_physical_address (CPUStat
if (address <= (int32_t)0x7FFFUL) {
/* useg */
-if (!(env->CP0_Status & (1 << CP0St_ERL) && user_mode)) {
+if (!(env->CP0_Status & (1 << CP0St_ERL))) {
ret = env->map_address(env, physical, prot, address, rw,
access_type);
} else {
*physical = address & 0x;
Index: target-mips/op.c
===
RCS file: /sources/qemu/qemu/target-mips/op.c,v
retrieving revision 1.65
diff -u -d -p -r1.65 op.c
--- target-mips/op.c29 May 2007 16:52:56 - 1.65
+++ target-mips/op.c14 Jun 2007 19:32:56 -
@@ -297,8 +297,8 @@ void op_addr_add (void)
with Status_UX = 0 should be casted to 32-bit and sign extended.
See the MIPS64 PRA manual, section 4.10. */
#ifdef TARGET_MIPS64
-if ((env->CP0_Status & (1 << CP0St_UM)) &&
-!(env->CP0_Status & (1 << CP0St_UX)))
+if ((env->hflags & MIPS_HFLAG_UM) &&
+!(env->CP0_Status & (1 << CP0St_UX)))
T0 = (int64_t)(int32_t)(T0 + T1);
else
#endif
@@ -1606,10 +1614,8 @@ void op_dmfc0_errorepc (void)
void op_cp0_enabled(void)
{
-if (!(env->CP0_Status & (1 << CP0St_CU0)) &&
- (env->hflags & MIPS_HFLAG_UM)) {
+if (!(env->CP0_Status & (1 << CP0St_CU0)))
CALL_FROM_TB2(do_raise_exception_err, EXCP_CpU, 0);
-}
RETURN();
}
Index: target-mips/translate.c
===
RCS file: /sources/qemu/qemu/target-mips/translate.c,v
retrieving revision 1.93
diff -u -d -p -r1.93 translate.c
--- target-mips/translate.c 2 Jun 2007 00:25:12 - 1.93
+++ target-mips/translate.c 14 Jun 2007 19:32:56 -
@@ -2642,6 +2642,7 @@ static void gen_mtc0 (CPUState *env, Dis
case 12:
switch (sel) {
case 0:
+save_cpu_state(ctx, 0);
gen_op_mtc0_status();
/* BS_STOP isn't good enough here, hflags may have changed. */
gen_save_pc(ctx->pc + 4);
@@ -2807,6 +2808,7 @@ static void gen_mtc0 (CPUState *env, Dis
case 23:
switch (sel) {
case 0:
+save_cpu_state(ctx, 0);
gen_op_mtc0_debug(); /* EJTAG support */
/* BS_STOP isn't good enough here, hflags may have changed. */
gen_save_pc(ctx->pc + 4);
@@ -4147,6 +4149,7 @@ static void gen_cp0 (CPUState *env, Disa
break;
case OPC_ERET:
opn = "eret";
+save_cpu_state(ctx, 0);
gen_op_eret();
ctx->bstate = BS_EXCP;
break;
@@ -4156,6 +4159,7 @@ static void gen_cp0 (CPUState *env, Disa
MIPS_INVAL(opn);
generate_exception(ctx, EXCP_RI);
} else {
+save_cpu_state(ctx, 0);
gen_op_deret();
ctx->bstate = BS_EXCP;
}
@@ -5647,8 +5651,11 @@ static void decode_opc (CPUState *env, D
}
break;
case OPC_CP0:
-save_cpu_state(ctx, 1);
-gen_op_cp0_enabled();
+if (ctx->hflags & MIPS_HFLAG_UM)
+{
+save_cpu_state(ctx, 1);
+gen_op_cp0_enabled();
+}
op1 = MASK_CP0(ctx->opcode);
switch (op1) {
case OPC_MFC0:
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] CPUTLBEntry Question
On Thu, Jun 14, 2007 at 05:00:32PM +0300, Blue Swirl wrote: > On 6/14/07, amateur <[EMAIL PROTECTED]> wrote: > >The softmmu_header.h code does assume each TLB entry has a fixed size > >of (2^CPU_TLB_ENTRY_BITS) bytes. Not only the assembly code, but also > >the C code assume this. So if you want to add new members into > >CPUTLBEntry, add the new member at the end of the data structure, and > >adjust CPU_TLB_ENTRY_BITS accordingly. > > No, on Sparc32 target_ulong is 32 bits (on 32-bit host) but > target_phys_addr_t is 64 bits. That makes the structure size 20 bytes. > Everything still works. - Oh, yes. It's my fault. I confused CPU_TLB_SIZE and CPU_TLB_ENTRY_BITS. Paul Brook is right. The C code works with any CPUTLBEntry layout. -- [32m题目:《村行》[m [33m作者:王禹称（繁体“称”，换“亻”旁）（９５４－１００１）[m 马穿山径菊初黄，信马悠悠野兴长。 万壑有声含晚籁，数峰无语立斜阳。 棠梨叶落胭脂色，荞麦花开白雪香。 何事吟余忽惆怅，村桥原树似吾乡。
[Qemu-devel] ANN: DetaolB v0.3 is released
DetaolB v0.3 is being released 14th,June 2007 on sf.net => http://sourceforge.net/project/showfiles.php?group_id=140321&package_id=155481&release_id=516140 - this is mostly a release with tons of added features - this is mostly a proof of concept - this is not a bugfix release - your feedback will shape it into v1.0 someday, so please post at the DetaolB mailing list: [EMAIL PROTECTED] Changelog: == - it's bigger now: ~17Mb, but it's still smaller than slax-frodo :) - you can still log using root with no password (this will change) - kernel 2.6.21 with following patches... * acpi, ide/atapi drivers added * /proc/miniconfig.gz: main ideas from Rob Landley, need documentation * aufs: another unionfs * squashfs * lzma vmlinux: a great thanks to Ming Ching Tiew! * complete git patches released on sf.net - still based on initramfs early userspace, now using switch_root * 1st phase is using a minimal static bbox * 2nd phase is mounting cdrom and 5 squashfs modules in aufs new root. This is a common scheme inspired by slax, yet simplified for speed. * 3rd phase is root switching and over to standard init phase * main drawback: changes to the rootfs are lost if you reboot. I've not figured out a smart way using initramfs+aufs+squashfs and access rootfs changes from RAM... * but it's still blazing fast even in qemu! - 5 default squashfs modules are present and enabled * "barebone" is busybox-1.6.0 with rootfs config files + mksquashfs * "uclibc" is uClibc-0.9.29 + zlib * "ncurses" is ncurses-5.2, needed for uclibc/bbox/kernel compilation * "toolchain" is needed for C compilation + gcc-3.4.6 + binutils-2.16.1 + bash-3.2 + bison-2.1 + flex-2.5.33 + make-3.81 + misc. coreutils mandatory for uclibc/bbox/kernel compilation * "vim" is a full vim-7.1 installation * these modules were compiled using DetaolB v0.3, and config files for uclibc and busybox are inside /root * "git" is compiled but not included yet - a 2.6.17 version of DetaolB v0.3 exist for colinux! it'll be available on demand, or will be released anyway at version 1.0 HOW TO USE IT ? === - use your favorite emulator: qemu, virtualbox, even vmplayer! - you need to provide an hda image preformatted in ext2 if you want to work on a non-volatile area (busybox has no more ext2fs tools ??) - boot it, do some compilation, enjoy it - please note it has no network capabilities - this distro is not meant for real hardware yet (but it will be soon) FEEDBACK, QUESTIONS, INSULTS, POSTCARDS: [EMAIL PROTECTED] -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] CPUTLBEntry Question
On 6/14/07, Paul Brook <[EMAIL PROTECTED]> wrote: > then QEMU crashes on startup. (It also crashes if I put that blah > entry on the beginning instead of the end.) I'm sure there's code > somewhere that must be making assumptions about the size of TLB entry, > but I'm at a loss for finding it. (I have noticed that the assembly > code in softmmu_header.h indexes to the addend based on addr_read or > addr_write, but adding a new member to the end of the structure > shouldn't impact that, right?) Wrong. The assembly implementation assumes CPUTLBEntry is 16 bytes (or to be exact 1 << CPU_TLB_ENTRY_BITS). The C implementation in softmmu_header.h will work with any layout. Paul That fixed/answered everything for me. Thanks for your help, everyone. Thanks Ryan
[Qemu-devel] logging the sdl test error
This is short configure patch which saves the output of the libsdl test comile
output
for a file which can be reviewed after configure runs. This allows for easier
debugging
of why the libSDL test failed.
Ben--- qemu/configure.ORIG 2007-06-14 13:58:26.144281000 -0400
+++ qemu/configure 2007-06-14 14:07:40.975474000 -0400
@@ -547,7 +547,7 @@
int main( void ) { return SDL_Init (SDL_INIT_VIDEO); }
EOF
-if $cc -o $TMPE `$sdl_config --cflags 2> /dev/null` $TMPC `$sdl_config --libs 2> /dev/null` 2> /dev/null ; then
+if $cc -o $TMPE `$sdl_config --cflags 2> /dev/null` $TMPC `$sdl_config --libs 2> /dev/null` 2> /tmp/qemu-sdl-config.log ; then
_sdlversion=`$sdl_config --version | sed 's/[^0-9]//g'`
if test "$_sdlversion" -lt 121 ; then
sdl_too_old=yes
@@ -572,6 +572,8 @@
fi # static link
+else
+ check_sdl_log="yes"
fi # sdl compile test
fi # cross compilation
@@ -682,6 +684,9 @@
if test $sdl_too_old = "yes"; then
echo "-> Your SDL version is too old - please upgrade to have SDL support"
fi
+if test "$check_sdl_log" = "yes"; then
+ echo "The error log from compiling the libSDL test is in /tmp/qemu-sdl-config.log"
+fi
#if test "$sdl_static" = "no"; then
# echo "WARNING: cannot compile statically with SDL - qemu-fast won't have a graphical output"
#fi
Re: [Qemu-devel] Debugging guest OS / tracing instruction pointer
Paul Brook wrote: On Thursday 14 June 2007, Clemens Kolbitsch wrote: hi! i'm looking for a way to monitor the eip register. is there a simple way to do this? i know that that produces tons of data... even better would be to know where i could intercept the main-loop (exec_cpu ??) to check for a certain eip value... qemu already has mechanisms for supporting debugger breakpoints. Sounds like you want something very similar. Paul the thing is: i want to monitor the eip... or where the code will jump NEXT. the code there is never executed (as it results in a kernel failure) e.g. i know a buffer overflow will set the return-pointer to 0xABCD and "ret" is executed i want the breakpoint to hit when using casual breakpoints, i think the code there must be executed (i.e. the jump must be successful .. what will definitely not be the case with 0xABCD) thanks!
Re: [Qemu-devel] Debugging guest OS / tracing instruction pointer
On Thursday 14 June 2007, Clemens Kolbitsch wrote: > hi! > i'm looking for a way to monitor the eip register. is there a simple way > to do this? i know that that produces tons of data... > > even better would be to know where i could intercept the main-loop > (exec_cpu ??) to check for a certain eip value... qemu already has mechanisms for supporting debugger breakpoints. Sounds like you want something very similar. Paul
[Qemu-devel] Debugging guest OS / tracing instruction pointer
hi! i'm looking for a way to monitor the eip register. is there a simple way to do this? i know that that produces tons of data... even better would be to know where i could intercept the main-loop (exec_cpu ??) to check for a certain eip value... could someone assist me doing that? thanks!
Re: [Qemu-devel] CPUTLBEntry Question
On 6/14/07, amateur <[EMAIL PROTECTED]> wrote: The softmmu_header.h code does assume each TLB entry has a fixed size of (2^CPU_TLB_ENTRY_BITS) bytes. Not only the assembly code, but also the C code assume this. So if you want to add new members into CPUTLBEntry, add the new member at the end of the data structure, and adjust CPU_TLB_ENTRY_BITS accordingly. No, on Sparc32 target_ulong is 32 bits (on 32-bit host) but target_phys_addr_t is 64 bits. That makes the structure size 20 bytes. Everything still works.
Re: [Qemu-devel] CPUTLBEntry Question
On Wed, Jun 13, 2007 at 04:25:07PM -0400, Ryan Riley wrote:
> typedef struct CPUTLBEntry {
>/* bit 31 to TARGET_PAGE_BITS : virtual address
> bit TARGET_PAGE_BITS-1..IO_MEM_SHIFT : if non zero, memory io
> zone number
> bit 3 : indicates that the entry is invalid
> bit 2..0 : zero
>*/
>target_ulong addr_read;
>target_ulong addr_write;
>target_ulong addr_code;
>/* addend to virtual address to get physical address */
>target_phys_addr_t addend;
> } CPUTLBEntry;
>
> If I change it to add another member, like so..
>
> typedef struct CPUTLBEntry {
>/* New member */
>target_phys_addr_t blah;
> } CPUTLBEntry;
>
> then QEMU crashes on startup. (It also crashes if I put that blah
> entry on the beginning instead of the end.) I'm sure there's code
> somewhere that must be making assumptions about the size of TLB entry,
> but I'm at a loss for finding it. (I have noticed that the assembly
> code in softmmu_header.h indexes to the addend based on addr_read or
> addr_write, but adding a new member to the end of the structure
> shouldn't impact that, right?)
-
The softmmu_header.h code does assume each TLB entry has a fixed size
of (2^CPU_TLB_ENTRY_BITS) bytes. Not only the assembly code, but also
the C code assume this. So if you want to add new members into
CPUTLBEntry, add the new member at the end of the data structure, and
adjust CPU_TLB_ENTRY_BITS accordingly.
Best Regards
Tianlei Zhao
--
Don't look back, the lemmings are gaining on you.
Re: [Qemu-devel] CPUTLBEntry Question
> then QEMU crashes on startup. (It also crashes if I put that blah > entry on the beginning instead of the end.) I'm sure there's code > somewhere that must be making assumptions about the size of TLB entry, > but I'm at a loss for finding it. (I have noticed that the assembly > code in softmmu_header.h indexes to the addend based on addr_read or > addr_write, but adding a new member to the end of the structure > shouldn't impact that, right?) Wrong. The assembly implementation assumes CPUTLBEntry is 16 bytes (or to be exact 1 << CPU_TLB_ENTRY_BITS). The C implementation in softmmu_header.h will work with any layout. Paul
[Qemu-devel] CPUTLBEntry Question
I'm making some small changes to the TLB stuff in QEMU 0.9.0
(specifically, I'm only working with i386-softmmu) and have run into
an odd question I'm hoping someone can answer for me. The CPUTLBEntry
structure definition in cpu-defs.h looks like this...
typedef struct CPUTLBEntry {
/* bit 31 to TARGET_PAGE_BITS : virtual address
bit TARGET_PAGE_BITS-1..IO_MEM_SHIFT : if non zero, memory io
zone number
bit 3 : indicates that the entry is invalid
bit 2..0 : zero
*/
target_ulong addr_read;
target_ulong addr_write;
target_ulong addr_code;
/* addend to virtual address to get physical address */
target_phys_addr_t addend;
} CPUTLBEntry;
If I change it to add another member, like so..
typedef struct CPUTLBEntry {
/* bit 31 to TARGET_PAGE_BITS : virtual address
bit TARGET_PAGE_BITS-1..IO_MEM_SHIFT : if non zero, memory io
zone number
bit 3 : indicates that the entry is invalid
bit 2..0 : zero
*/
target_ulong addr_read;
target_ulong addr_write;
target_ulong addr_code;
/* addend to virtual address to get physical address */
target_phys_addr_t addend;
/* New member */
target_phys_addr_t blah;
} CPUTLBEntry;
then QEMU crashes on startup. (It also crashes if I put that blah
entry on the beginning instead of the end.) I'm sure there's code
somewhere that must be making assumptions about the size of TLB entry,
but I'm at a loss for finding it. (I have noticed that the assembly
code in softmmu_header.h indexes to the addend based on addr_read or
addr_write, but adding a new member to the end of the structure
shouldn't impact that, right?)
If anyone has any insight, I would be very appreciative.
Thanks
Ryan
[Qemu-devel] [PATCH] Add a 7 segments + led display #2
Hi, This patch adds a 7-segments + led display device emulation to Qemu. A picture of the original thing can be found at http://www.sensi.org/~alec/mips/images/acer_pica_io_3.jpg Use the device in the MIPS PICA 61 machine. Modified to take care of 8, 15, 16, 24 and 32 bit color depths. Hervé jazz_led_2.diff Description: Binary data
