[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
[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
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
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.
[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] 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
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!
[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] 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 马穿山径菊初黄，信马悠悠野兴长。 万壑有声含晚籁，数峰无语立斜阳。 棠梨叶落胭脂色，荞麦花开白雪香。 何事吟余忽惆怅，村桥原树似吾乡。
