Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs

["J. Mayer" <l_indien@magic.fr>]

On Sun, 2007-11-04 at 09:12 +0200, Blue Swirl wrote:
> On 11/4/07, Fabrice Bellard <fabrice@bellard.org> 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 <l_indien@magic.fr>
Never organized