QEMU-1.2.0 based TLMu

[yTakatsukasa]

Hi Edgar,
I have 'rebase'd tlmu onto QEMU-1.2.0.
Rebase command of git did not help because QEMU core has changed pretty much. Ofcourse you know :)
I had to rewrite the memory access hooks.

Now tlm_mem is treated as ramd which is almost as same as romd of QEMU.
I have added another mem_map function, tlmu_map_ram_nosync().
Memories specified with tlmu_map_ram_nosync() is accessed via DMI without any timing calculation.
Search walk of TLMRegisterRamEntry never happens anymore.

Linux on ARM now boots up in 3sec, which is 7 times faster.

I only tested the functionality of ARM.
There must be new bugs about timing calculation and syncing.

I am planning to keep up with mainline QEMU release.

If you are interested, please try tlmu-1.2.0 branch on our repository.
https://github.com/hdlab/tlmu/tree/tlmu-1.2.0

Best regards,
Yutetsu.

[edgarigl]

On Thu, Nov 01, 2012 at 03:06:29AM -0700, Yutetsu TAKATSUKASA wrote:

Hi Edgar,
I have 'rebase'd tlmu onto QEMU-1.2.0.
Rebase command of git did not help because QEMU core has changed pretty much.
Ofcourse you know :)
I had to rewrite the memory access hooks.
Now tlm_mem is treated as ramd which is almost as same as romd of QEMU.
I have added another mem_map function, tlmu_map_ram_nosync().
Memories specified with tlmu_map_ram_nosync() is accessed via DMI without any
timing calculation.
Search walk of TLMRegisterRamEntry never happens anymore.
Linux on ARM now boots up in 3sec, which is 7 times faster.
I only tested the functionality of ARM.
There must be new bugs about timing calculation and syncing.
I am planning to keep up with mainline QEMU release.
If you are interested, please try tlmu-1.2.0 branch on our repository.
https://github.com/hdlab/tlmu/tree/tlmu-1.2.0
Best regards,
Yutetsu.

Hi,

This looks like cool stuff! I'm going to give it a try but am pretty
busy for two weeks or so, sorry.

A few questions:

1. The testsuite that was in place in before, with mips, arm and cris
   guests running in parallel on the same virtual system. Do these still
   work?
2. Could you explain the system you test with a little more?
   Does the TLM world initiate accesses into TLMu aswell?
3. Can the TLM world access memory areas in TLMU mapped as turbo mode?

Thanks for working on this!

Best regads,
Edgar

[yTakatsukasa]

Hi

1 The testsuite that was in place in before, with mips, arm and cris guests running in parallel on the same virtual system. Do these still work?

Yes. But output looks changed. It shows like below on my computer. They looks running sequentially.
I guess the reason for this change is usage of pthread has been changed in QEMU. TCG thread??? not sure.

Hello, I am the ARM
ARM: STOP: 0
Hello, I am the CRIS
CRIS: STOP: 0
Hello, I am the MIPSEL
MIPS: STOP: 0

2 Could you explain the system you test with a little more? Does the TLM world initiate accesses into TLMu aswell?

No.
Only ARM926 is in TLMu and other modules like memories, timers are in TLM(SystemC) world.

Whole environment can be downloaded from http://www.hdlab.co.jp/web/a050consulting/b009armcpumodel/
I am very sorry to tell you that the registration is required and everything is written only in Japanese.

3 Can the TLM world access memory areas in TLMU mapped as turbo mode?

Not tested, but it should.
Accessing TLMu from TLM world invokes cpu_physical_memory_rw() or cpu_physical_memory_rw_debug().
These functions are always used when CPU in TLMu accesses QEMU-inside devices or TLM world.
So maybe OK.

Let me summarize the memory access handling in my implementation.

• If devices or memory is mapped with tlmu_map_ram()
  Mapped devices are treated as ramd.
  They are accessed via tlm_read() or tlm_write() called by cpu_physical_memory_rw().
• If memory is mapped with tlmu_map_ram_nosync()
  DMI pointer is directly passed to QEMU memory_region_init_ram_ptr().
  The memory is treated as a normal QEMU memory not as ramd.
  It is accessible via cpu_physical_memory_rw().
  If DMI r/w access is not allowed for the memory, then fallbacks to tlmu_map_ram()

Regards,
Yutetsu.