Re: [Qemu-devel] Re: [PATCH 2/6] qemu-kvm: Modify and introduce wrapper functions to access phys_ram_dirty.

[Avi Kivity]

On 03/17/2010 06:06 PM, Paul Brook wrote:
> > On 03/16/2010 10:10 PM, Blue Swirl wrote:
> >      
> > > >    Yes, and is what tlb_protect_code() does and it's called from
> > > > tb_alloc_page() which is what's code when a TB is created.
> > > >          
> > > Just a tangential note: a long time ago, I tried to disable self
> > > modifying code detection for Sparc. On most RISC architectures, SMC
> > > needs explicit flushing so in theory we need not track code memory
> > > writes. However, during exceptions the translator needs to access the
> > > original unmodified code that was used to generate the TB. But maybe
> > > there are other ways to avoid SMC tracking, on x86 it's still needed
> > >        
> > On x86 you're supposed to execute a serializing instruction (one of
> > INVD, INVEPT, INVLPG, INVVPID, LGDT, LIDT, LLDT, LTR, MOV (to control
> > register, with the exception of MOV CR8), MOV (to debug register),
> > WBINVD, WRMSR, CPUID, IRET, and RSM) before running modified code.
> >      
> Last time I checked, a jump instruction was sufficient to ensure coherency
> withing a core.  Serializing instructions are only required for coherency
> between cores on SMP systems.
>    

Yeah, the docs say either a jump or a serializing instruction is needed.

> QEMU effectively has a very large physically tagged icache[1] with very
> expensive cache loads.  AFAIK The only practical way to maintain that cache on
> x86 targets is to do write snooping via dirty bits. On targets that mandate
> explicit icache invalidation we might be able to get away with this, however I
> doubt it actually gains you anything - a correctly written guest is going to
> invalidate at least as much as we get from dirty tracking, and we still need
> to provide correct behaviour when executing with cache disabled.
>    

Agreed.

>    
> > > but I suppose SMC is pretty rare.
> > >        
> > Every time you demand load a code page from disk, you're running self
> > modifying code (though it usually doesn't exist in the tlb, so there's
> > no previous version that can cause trouble).
> >      
> I think you're confusing TLB flushes with TB flushes.
>    

No - my thinking was page fault, load page, invlpg, continue.  But the 
invlpg is unneeded, and "continue" has to include a jump anyway.

--
error compiling committee.c: too many arguments to function