Re: [Qemu-devel] sh: dcache flush breaks text region?

[Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp>]

Edgar E. Iglesias wrote:
> On Sun, Jan 11, 2009 at 02:38:48AM +0900, Shin-ichiro KAWASAKI wrote:
>> Hi, all.
>>
>> I'm now working on to expand qemu-sh to emulate
>> "Solution Engine 7750", and found one odd thing.
>> Could you give me some advice?
>>
>> My SH7750 emulation environment fails to boot up.
>> I made some investigation and found that,
>>  - the linux kernel for SE7750(se7750_defconfig) flushes
>>    dcache on its boot sequence.
>>  - SH7750's dcache is 16KB and direct-map.
>>    Then 16KB memory region are touched and modified to flush it.
>>  - empty_zero_page is used for this flush, but it only has
>>    4KB.  The text region after it has got broken and causes
>>    boot failure.
>>
>> I added a patch against linux kernel to this mail for a reference.
>> It only reduces the flush region size to 4KB=PAGE_SIZE, but avoids
>> the problem and let the kernel boot up cleanly.
>> Of course it is not a good solution, because it does not flush all
>> caches.
>>
>> I wonder two points.
>>  - Does this problem happen on real SE7750 board?
> 
> Hello,
> 
> I'm not very familiar with sh arch so please take this with a grain
> of salt :)
> 
> It's not entirely clear to me if the bug will show up on silicon, but my
> guess is that it wont.
> 
>>From my understating of the docs, the movca store will for misses in the
> cache be processed with a write-validate write-miss policy. That means that
> the movca store will allocate the line (flushing any previous content if
> needed) but not fetch any data corresponding to the movca store address.
> The sh7750 does not have multiple dirty bits per line so that kind of
> treatment leaves the unwritten parts of the line with unpredictable results.
> 
> Such insns can be very useful for fast block copies through writeback caches
> that otherwise do a line fetch for write-misses.
> 
> So, when the ocbi insn invalidates the line, no write back is done and the
> downstream busses never see the movca store.

Thanks a lot!  This explains the situation.
I haven't understood what movca does.

> I'm not sure how to handle this in qemu without adding cache models.
That seems a too big work and might have performance drawback.

> One way to handle this particular cacheflush sequence might be to delay all
> movca stores until there's another load/store or cache control insn being
> issued to help you figure out if you can ignore previous movca. That will
> not by any means cover all cases though.
It seems a good way to avoid this problem.
My current modification plan is as follows.
 - On executing 'movca', just record the store task which movca
   should do into CPUStatus.
 - On executing 'ocbi', delete the store task.
 - Let TCG produce 'delayed_movca' instruction for
   the first 'memory touching insn' or 'exception producing insn'
   after movca.
 - On executing 'delayed_movca', do the store tasks. 

> Another solution might be for linux to use a ocpb followed by a ocpi insn
> on the line. IIUC that should achieve the same results net results.
I'm not sure about it.  But I think we should not modify linux,
because now I guess that the current linux works on real silicon. 

Thanks again!

Regards,
Shin-ichiro KAWASAKI