[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] bug: qemu-0.9.0 emulating mipsel (32-bit R3000) on amd6
From: |
Thiemo Seufer |
Subject: |
Re: [Qemu-devel] bug: qemu-0.9.0 emulating mipsel (32-bit R3000) on amd64 |
Date: |
Wed, 9 May 2007 02:04:25 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
John Reiser wrote:
> >>qemu-0.9.0 ...
> >>emulating Debian 2.6.18-4-qemu mipsel ...
> >>errs when gdb 6.4.90-debian (running on the emulated mipsel)
> >>single-steps the user-mode instruction ...
>
> > This looks like another instance of "Qemu/MIPS doesn't handle
> > self-modifying code correctly" (the break instructions inserted
> > by gdb are exactly this).
>
> No, the usage by gdb does *not* qualify as "self-modifying code."
In the context of Qemu system emulation it does...
> gdb uses the system call ptrace(PTRACE_POKETEXT, pid, addr, data)
> to have the emulated operating system kernel itself modify the memory
> of the child process.
... since "child processes" etc. run by the guest kernel are just a
foreign thing to Qemu.
> Nobody has to guess or to "snoop" the memory
> bus in order to discover that the instruction stream is being modified.
> Instead, there is direct notification of what is happening.
The Linux kernel happily does cache flushes, and Qemu happily ignores
them, since it doesn't implement a cache model. (A cache model is not
the answer. It would be slow, it would only paper over the problem,
it wouldn't help for uncached accesses or cacheless systems).
> If nothing
> else, then under CONFIG_QEMU the implementation of sys_ptrace()
> must notify the emulator to flush the appropriate translations.
Hacking special facilities in the guest kernel just to work around
a Qemu bug is IMHO the wrong approach.
Thiemo