qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]