Dear Jason,
Thank you for your reply. I am not looking for the "data" in that memory location; I am just confused with the inconsistent memory address comparing the assembly code and the dumped memory access during runtime. As the example shown below, and let's suppose register %rdx equals to 12 at this moment. 0x404a83: movzbl 0x5891e0(%rdx),%eax So we can actually expect a memory access towards memory location 0x5891e0 + 12 = *0x5891ec*. However, in the captured memory access between CPU and L1 DCache, the captured memory access is towards something like "497492449", or "499049121" (the example I gave in the previous email). As Ferran said (thank you Ferran!), the dumped "499049121" or 497492449 are actually physical memory address, while the *0x5891ec *is definitely virtual address. So here is my question: 1. Can I actually get the virtual memory address instead of the physical address when using the monitoring facilities? 2. I am actually trying to use the virtual memory address to calculate the accessed cache line number (divide the virtual memory address by the cache line size, which is 64), is there any way I can calculate the accessed cache line number by using the physical memory address? Can I still go with the "divide by 64"? Sorry if this question is too naive... Thank you in advance! Sincerely, Shuai On Mon, Jan 2, 2017 at 10:56 AM, Jason Lowe-Power <[email protected]> wrote: > Hi Shuai, > > Are you looking for the data that is in guest address 0x5891e1? If so, I > would create a new Request and Packet object and use the then send a > functional request to the memory system. The AbstractMemory object that > represents the main-memory of the guest (e.g., DDR3_1600... or whatever > memory type you are using) has a pointer to a memory-mapped region on the > host which contains the guest's physical memory. It may be possible to > directly access this in your code, but this is a bad idea as caches may > contain more up-to-date data. The functional access is meant to get the > current data for the request without causing any guest timing variation. > > Hope this helps, > Jason > > On Wed, Dec 28, 2016 at 2:48 PM Shuai Wang <[email protected]> wrote: > >> Hello Ferran, >> >> Thank you so much for your help! I tried the approach you suggested, and >> it works pretty well! I really appreciate your help :) >> >> After going through the tracked memory access information, there is still >> one thing that confuses me a lot. At your connivence, could you please take >> a look and shed some light on it? Thank you a lot in advance. >> >> >> Suppose I am trying to analyze the cache access of the instruction below: >> >> 0x404a83: movzbl 0x5891e0(%rdx),%eax >> >> In the dumped trace, by searching the program counter (i.e., 0x404a83), I >> observed two cache access of the above instruction (very consistent with my >> inference on the source code, which's great ! ) like below: >> >> r,497492449,1,3,5587298761000,4213379 >> ... >> r,499049121,1,3,5608120191500,4213379 >> ... >> >> The value in the second column should be the accessed memory address of >> each cache access, which is 497492449 or 499049121. >> >> However, my debugging results of the above instruction on a physical >> machine shows that register %rdx equals to 1 or 193, and the corresponding >> accessed memory address should be 0x5891e0 + 1 = 0x5891e1 or 0x5891e0 + >> 193 = 5804705. >> >> I understood that memory address could be very different comparing the >> physical machine with the gem5 simulated machine. However, I basically have >> no idea how should I interpret the tracked memory addresses. For example, >> one accessed memory address is larger than the other one in terms of 192 on >> the physical machine, while I cannot figure out such relation in the >> simulated results... >> >> Is there any way I can interpret/translate the captured memory addresses >> on the simulated OS into corresponding memory addresses on the physical >> machines? Or basically there is no way to do that...? >> >> >> Any suggestion would be really appreciated! Thank you a lot and wish you >> all the best! >> >> Sincerely, >> Shuai >> >> >> On Wed, Dec 28, 2016 at 5:10 AM, Ferran Olid <[email protected]> >> wrote: >> >> 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 >> [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 >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > -- > > Jason > > _______________________________________________ > 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
