qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code suppo


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH, RFC] Disable implicit self-modifying code support for RISC CPUs
Date: Sun, 4 Nov 2007 09:49:02 +0200

On 11/4/07, J. Mayer <address@hidden> wrote:
>
> On Sun, 2007-11-04 at 09:12 +0200, Blue Swirl wrote:
> > On 11/4/07, Fabrice Bellard <address@hidden> 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...

In fact Sparc code calls only tlb_set_page_exec, never tlb_set_page,
so no fix is necessary.

This reminds me that there is some TARGET_SPARC conditional code in
fdc.c, I'll change those.




reply via email to

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