On Sun, 2007-11-04 at 09:12 +0200, Blue Swirl wrote: > On 11/4/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote: > > Blue Swirl wrote: > > > Hi, > > > > > > RISC CPUs don't support self-modifying code unless the affected area > > > is flushed explicitly. This patch disables the extra effort for SMC. > > > The changes in this version would affect all CPUs except x86, but I'd > > > like to see if there are problems with some target, so that the > > > committed change can be limited. Without comments, I'll just disable > > > SMC for Sparc, as there are no problems. So please comment, especially > > > if you want to "opt in". > > > > > > For some reason, I can't disable all TB/TLB flushing, for example > > > there was already one line with TARGET_HAS_SMC || 1, but removing the > > > || 1 part causes crashing. Does anyone know why? > > > > With the current QEMU architecture, you cannot disable self-modifying > > code as you did. This is why I did not fully supported the > > TARGET_HAS_SMC flag. The problem is that the translator make the > > assumption that the RAM and the TB contents are consistent for example > > when handling exceptions. Suppressing this assumption is possible but > > requires more work. > > I think the conclusion is that we would need some kind of emulator for > i-cache for any accurate emulation. And handling the boot loader may > need an uncached mode.
> The performance benefit from disabling SMC is unnoticeable according > to my benchmarks. Adding a TB flush to i-cache flushing made things > worse. Moreover, SMC is hardly ever used on Sparc. > > I'll just commit the debug statement fixes and > the fix that separates > PAGE_READ from PAGE_EXEC for Sparc. This patch is absolutely not needed. You have to directly call tlb_set_page_exec instead of tlb_set_page if you want to separate PAGE_READ from PAGE_EXEC. #ifdef TARGET_xxx should never occur in generic code and in that specific case, it's the Sparc target code that has to be fixed... > Maybe this issue should be documented in qemu-tech.texi, there are > also frequently some questions about caches. Yes, some documentation on such tricks can never hurt ! -- J. Mayer <[EMAIL PROTECTED]> Never organized