Hi Shuai,
What you could do is booting the system with the atomic CPU and just
when finished booting, create a checkpoint and exit (you can do this
with the flag --checkpoint-at-exit or something like this). Afterwards,
you resume the checkpoint using the CPU you want and monitoring
everything. In addition, if you do it this way you can modify the memory
hierarchy or the CPU model and, as long as there are no changes in the
script or in the disk you're using for the full system, there's no need
to boot it again.
Hope this helped,
Ferran O
On 28/12/16 04:35, Shuai Wang wrote:
Dear list,
I am using gem5 full system simulation to run a 64-bit x86
application, and trying to capture the memory access towards the L1
DCache.
I have successfully setup the whole full system simulation environment
(Ubuntu 12.04 64-bit, Kernel version 3.2.1). I modified the code
in configs/common/CacheConfig.py to equip my simulated system with
L1 ICache and DCache, and intercept the communication between CPU and
DCache with a common monitoring.
My current observation is that, during the booting of the simulated
system, it seems stuck at the *init_memory_mapping *procedure**after
almost half an hour. I past the output of the booting process below:
☁ term [master] ⚡ ./m5term localhost 3456
==== m5 slave terminal: Terminal 0 ====
Linux version 3.2.1 (szw175@lrs-dwu01) (gcc version 4.8.1 (Ubuntu
4.8.1-2ubuntu1~12.04) ) #2 Tue Dec 27 14:24:46 EST 2016
Command line: earlyprintk=ttyS0 console=ttyS0 lpj=7999923 root=/dev/hda1
CPU: vendor_id 'M5 Simulator' unknown, using generic init.
CPU: Your system may be unstable.
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
BIOS-e820: 0000000020000000 - 00000000c0000000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
bootconsole [earlyser0] enabled
NX (Execute Disable) protection: active
DMI 2.5 present.
No AGP bridge found
last_pfn = 0x20000 max_arch_pfn = 0x400000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
CPU MTRRs all blank - virtualized system.
found SMP MP-table at [ffff8800000f0050] f0050
init_memory_mapping: 0000000000000000-0000000020000000
I understand that such CPU<->DCache monitoring could be very time
consuming, and it seems reasonable for such slow booting. However, I
would like to inquire about two questions at this step, in case I
didn't screw things up..
1. Note that I am trying to monitor the cache access of an application
code in the simulated OS, so basically it is meaningless to start the
monitoring at the very beginning. So I am wondering if there is any
chance that I can skip the monitoring during the OS booting; the
monitoring can start right after the OS booting.
My application code cannot run under the syscall simulation mode,
so that's why I need the full system mode..
2. Is there any "best practice" that I can use to boost the OS booting
procedure under monitoring?
Any advice or suggestion would be strongly appreciated! Thank you.
Sincerely,
Shuai
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
