Re: [gem5-dev] Architecture of gem5

[Potter, Brandon]

Yeah, I remember the "Linux process trackers"; they were my motivation for 
exploring the memory reads on the kernel structures. I wanted to extend them, 
but the source was closed so I started hacking around to implement my own.

Unfortunately, I don't get to use FS here at AMD much; we rely almost 
exclusively on SE for now. So, I don't know if it's possible to make Python 
scripts interact with a running kernel in FS. I suspect that it might be 
possible to build the mechanism easily enough though. You could create Python 
wrappers for C++ methods that read physical memory; the memory should be 
accessible through the "System" class. To make the equivalent of HAPs, you 
could create pseudo instructions and instrument a Linux kernel with them. 
Alternatively, you could add hooks into gem5 on register state changes to do 
some magical thing that you want to do. Hopefully someone else has something 
more constructive to say, but that's what comes to mind for me.

The caveat with this kind of thing is that we would have to maintain it as the 
Linux kernel moves forward to keep it working. The kernel developers have a 
tendency to change the symbols that are made available through 
kallsyms/System.map. Currently, I think that they're not even visible by 
default with a kernel; they turned them off for security reasons. We'd have to 
compile a new kernel with the switch flipped on. Anyways, I might not be a big 
deal, because we already package our FS kernels and post them on the gem5 
website.

This is a project that I've wanted to work on for the past few years, but I 
haven't had the time to devote to it. However, I do agree that this would be an 
excellent feature to add for research purposes.
 
-Brandon

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Boris 
Shingarov/Employee/LW-US
Sent: Friday, September 9, 2016 8:03 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Architecture of gem5

I remember back when I was using Simics, there were these things called "Linux 
process trackers" that did exactly that. It  was all written in Python, and 
there was a point when various  processor-specific trackers got simplified / 
pulled together into one  generic tracker in which only the truly ISA-dependent 
knowledge was  pushed down to subclasses like x86_ops/ppc_ops etc., which would 
 override methods like "syscall_num()" according with passing that num in  eax 
vs r0; or overriding "current_task()" according to the struct being  kept on 
the kernel stack vs pointed by sprg3, etc.
It would be  extremely interesting to have similar functionality in gem5, and I 
have  even thought about writing something like that myself, but I don't know  
much about the infrastructure that would allow one to hook up such  Python 
scripts to haps like "memory access breakpoint" or "interrupt" or  "user/kernel 
mode change" easily and even on-the-fly in the middle of  debugging the kernel. 
 If someone could provide an initial explanation  of what mechanisms are there 
beyond using Python for initial  configuration, it would serve as a push 
forward at least for me.

-"gem5-dev"  wrote: -
To: gem5 Developer List 
From: "Potter, Brandon" 
Sent by: "gem5-dev" 
Date: 09/08/2016 07:26PM
Subject: Re: [gem5-dev] Architecture of gem5

With full-system mode, you can do kernel introspection. The kernel resides in 
the simulated memory which you have complete control over; you can do whatever 
you want to do with it. The kernel is what is responsible for managing the 
processes and their memory so if you want interesting kernel-level information, 
you might look into reading the kernel's physical memory directly.

With complete access to the full memory layout, you can play tricks with the 
physical memory and OS symbols to access structures, namely task_struct and 
mm_struct. It's difficult to do this and requires a bit of trial and error to 
figure out which symbols the kernel exposes to allow you to do this, but it is 
possible. The trick is to read the hex values from physical memory and compare 
them with the Linux kernel source; you can reason about which fields are 
pointers and which have values that are defined in the source. It just takes 
work to puzzle out the rest. I did this once with Simics so it is possible, but 
it's time consuming.

If you obtain access to the task_struct list, you can get access to the 
mm_struct which give you the full memory layout for each process. With the full 
memory layout, you can discern which areas of each process' virtual address 
space are mapped and which physical frames (in the simulated memory) correspond 
to those virtual address. In this way, you can get both the virtual and 
physical addresses of addresses for any process.

As Jason mentioned, you can use /proc/{some_pid}/maps to figure out the virtual 
address ranges that are mapped (at a specific point in the 

Re: [gem5-dev] Architecture of gem5

[Potter, Brandon]

gem5/src/arch/x86/process.hh
gem5/src/arch/x86/process.cc
gem5/src/arch/x86/regs/misc.hh
gem5/src/arch/x86/regs/segment.hh

I'd look through full-system code and either find a hook or make one to allow 
access to the segment registers in the preceding files. It might take some time 
to figure that out, but this should get you started. 

-Brandon

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jasmin Jahic
Sent: Friday, September 9, 2016 12:45 AM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Architecture of gem5

@Jason, @Brandon, thank you very much for your explanations and references.
I will try to solve this and if I succeed I will post the solution.

I just have one more technical question. Where in gem5 I can track registers of 
the CPU? I am able to identify fetch, decode, execute phases, as well as the 
access to the abstract memory and cache pages. I am using atomic/simple CPU.

Best regards,
Jasmin

On Fri, Sep 9, 2016 at 1:50 AM, Potter, Brandon 
wrote:

> "If the sign extended bits are 1s, then the accesses are going 
> into kernel space and you can be reasonably sure that the kernel is 
> executing. So, the fool proof method is the CPL level in the code 
> segment register, but you can sometimes tell by the accesses if the 
> kernel is running or not."
>
> I just want to reiterate that this is not the best method, the kernel 
> can access user space virtual address so the kernel might be running 
> and you might see accesses to user-space virtual addresses, but it's 
> not guaranteed to tell whether you're in kernel mode or user mode. You 
> should really check the ring mode (if using X86).
>
> "With complete access to the full memory layout, you can play 
> tricks with the physical memory and OS symbols to access structures, 
> namely task_struct and mm_struct. It's difficult to do this and 
> requires a bit of trial and error to figure out which symbols the 
> kernel exposes to allow you to do this, but it is possible. The trick 
> is to read the hex values from physical memory and compare them with 
> the Linux kernel source; you can reason about which fields are 
> pointers and which have values that are defined in the source. It just 
> takes work to puzzle out the rest. I did this once with Simics so it is 
> possible, but it's time consuming."
>
> If you want to go down this rabbit hole, here are a couple of notes on 
> this. Firstly, you need to know about the kernel symbols (kallsyms), 
> https://onebitbug.me/2011/03/04/introducing-linux-kernel-symbols/. The 
> kallsyms get loaded from something in /boot (System.map I think or 
> some configuration file). Given these addresses, you can figure out 
> where the symbols are in physical memory and read their hex values.
>
> -Brandon
>
> -Original Message-
> From: Potter, Brandon
> Sent: Thursday, September 8, 2016 6:26 PM
> To: gem5 Developer List 
> Subject: RE: [gem5-dev] Architecture of gem5
>
> With full-system mode, you can do kernel introspection. The kernel 
> resides in the simulated memory which you have complete control over; 
> you can do whatever you want to do with it. The kernel is what is 
> responsible for managing the processes and their memory so if you want 
> interesting kernel-level information, you might look into reading the 
> kernel's physical memory directly.
>
> With complete access to the full memory layout, you can play tricks 
> with the physical memory and OS symbols to access structures, namely 
> task_struct and mm_struct. It's difficult to do this and requires a 
> bit of trial and error to figure out which symbols the kernel exposes 
> to allow you to do this, but it is possible. The trick is to read the 
> hex values from physical memory and compare them with the Linux kernel 
> source; you can reason about which fields are pointers and which have 
> values that are defined in the source. It just takes work to puzzle 
> out the rest. I did this once with Simics so it is possible, but it's time 
> consuming.
>
> If you obtain access to the task_struct list, you can get access to 
> the mm_struct which give you the full memory layout for each process. 
> With the full memory layout, you can discern which areas of each 
> process' virtual address space are mapped and which physical frames 
> (in the simulated
> memory) correspond to those virtual address. In this way, you can get 
> both the virtual and physical addresses of addresses for any process.
>
> As Jason mentioned, you can use /proc/{some_pid}/maps to figure out 
> the virtual address ranges that are mapped (at a specific point in the 
> execution of that process). Furthermore, you can use pagemap to figure 
> out what the physical address is. The catch with using these methods 
> is that the simulator has to be running and the process that you're 
> interested in examining has to be running to read the files 

Re: [gem5-dev] Review Request 3591: ruby: Allow multiple outstanding DMA requests

[Andreas Hansson]

> On Sept. 1, 2016, 3:33 p.m., Jason Lowe-Power wrote:
> > What testing did you perform to make sure all of the protocols were 
> > modified correctly?
> > 
> > Most of these changes seem reasonable to me, but I know from experience 
> > that even when the SLICC changes seem like they are right, if they aren't 
> > tested carefully there's almost always bugs.
> 
> Michael LeBeane wrote:
> The sequencer changes have been tested pretty thoroughly in a custom 
> protocol; the public SLICC files only with the regression tester.  I'm not 
> sure how much coverage that provides for DMA other than checking if it 
> compiles.
> 
> Jason Lowe-Power wrote:
> I'm not sure what to do about this. Maybe others in the community will 
> speak up ;).
> 
> I don't feel comfortable pushing a patch with code that we know hasn't 
> been tested at all. Specifically with Ruby/SLICC, this has bitten me before. 
> I've updated gem5 and all of sudden my simluations are broken because someone 
> changed a protocol without testing it. IMO, code needs to be tested at least 
> somewhat before it's pushed into the mainline.
> 
> However, I also understand that there isn't any testing infrastructure 
> for most of the protocols, and we can't ask you to solve that problem before 
> pushing the patch in.
> 
> Do others have thoughts on this (reoccurring) problem? 
> 
> For this specific patch, can you run your workload that use DMA with 
> protocols other than your internal protocol?
> 
> Michael LeBeane wrote:
> It would take some effort, but I do have some DMA intensive networking 
> benchmarks that should be able to run over the public protocols.  I wouldn't 
> be able to share these or add them to the regression tester (they are 
> proprietary).
> 
> I know that doesn't help at all with the more general problem of poor 
> tester coverage, but would that be an acceptable solution for this patch?
> 
> Jason Lowe-Power wrote:
> I would appreciate it if you ran those tests. It doesn't bother me nearly 
> as much that they are proprietary tests. At least we'll know that something 
> executed correctly with the other protocols! Improving the coverage of the 
> regression tests is hugely outside of the scope for this patch.
> 
> I'd still like to hear what others think about this problem in the longer 
> term.
> 
> Andreas Hansson wrote:
> Another potential issue: The queue of requests that has been created, 
> does it officially need to be visible to any functional access? In other 
> words, has it "happened" yet? For the queued ports we have functions to query 
> the queued packets on a functional access, but that does not seem to be 
> present in the patch.
> 
> Brad Beckmann wrote:
> I think Michael is a bit unsure how to move this patch forward in a 
> reasonable way.  Here are a couple things to consider:
> 
> - Jason, another way Michael could have approached this patch is simply 
> provided the changes to the DMASequencer and not touched the public 
> protocols.  Limiting these DMA controllers to only a single outstanding 
> request is obviously a big bottleneck, but we don't use these protocols at 
> AMD.  Michael really went beyond what was necessary here.  If he tests the 
> basically functionality of the public protocol changes, I think that is 
> enough.  We should minimize the burden for performance fixes to the public 
> protocols.
> - Andreas, in many of your recent Ruby code reviews, you've mentioned 
> concerns with functional accesses.  Perhaps we should arrange a separate 
> thread on the topic and clarify the current state of Ruby functional 
> accesses, as well as discuss your goals.  I'm pretty sure this patch is 
> orthogonal to functional accesses.  It is simply allowing multiple DMA 
> requests to be processed by the public DMA controllers.
> 
> Jason Lowe-Power wrote:
> I think this change is great, I would like to see it pushed in. I agree 
> that these changes are needed to get reasonable DMA performance. 
> 
> I agree that's enough to just test the basic functionality with the 
> public protocols. As long as these protocols have all been compiled, and any 
> workload that exercises DMA is run on the protocol, I'm happy.
> 
> In the past, there have been changes to Ruby protocols that weren't 
> tested at all. Then, sometimes months later, users (i.e., people down the 
> hall from me) have noticed that the protocols were broken, in some cases they 
> didn't even compile! Digging back through hundreds of changes to find out 
> what broke the protocol is incredibly time consuming, even with hg bisect. 
> IMO, we should strucure our code requirements to avoid this.
> 
> For now, I'm perfectly happy with just asking the question "Did you test 
> these changes?" and the reviewee replying "Yes". In the future we can work on 
> the regression test coverage.
> 
> I agree that functional access is out 

Re: [gem5-dev] Review Request 3591: ruby: Allow multiple outstanding DMA requests

[Jason Lowe-Power]

> On Sept. 1, 2016, 3:33 p.m., Jason Lowe-Power wrote:
> > What testing did you perform to make sure all of the protocols were 
> > modified correctly?
> > 
> > Most of these changes seem reasonable to me, but I know from experience 
> > that even when the SLICC changes seem like they are right, if they aren't 
> > tested carefully there's almost always bugs.
> 
> Michael LeBeane wrote:
> The sequencer changes have been tested pretty thoroughly in a custom 
> protocol; the public SLICC files only with the regression tester.  I'm not 
> sure how much coverage that provides for DMA other than checking if it 
> compiles.
> 
> Jason Lowe-Power wrote:
> I'm not sure what to do about this. Maybe others in the community will 
> speak up ;).
> 
> I don't feel comfortable pushing a patch with code that we know hasn't 
> been tested at all. Specifically with Ruby/SLICC, this has bitten me before. 
> I've updated gem5 and all of sudden my simluations are broken because someone 
> changed a protocol without testing it. IMO, code needs to be tested at least 
> somewhat before it's pushed into the mainline.
> 
> However, I also understand that there isn't any testing infrastructure 
> for most of the protocols, and we can't ask you to solve that problem before 
> pushing the patch in.
> 
> Do others have thoughts on this (reoccurring) problem? 
> 
> For this specific patch, can you run your workload that use DMA with 
> protocols other than your internal protocol?
> 
> Michael LeBeane wrote:
> It would take some effort, but I do have some DMA intensive networking 
> benchmarks that should be able to run over the public protocols.  I wouldn't 
> be able to share these or add them to the regression tester (they are 
> proprietary).
> 
> I know that doesn't help at all with the more general problem of poor 
> tester coverage, but would that be an acceptable solution for this patch?
> 
> Jason Lowe-Power wrote:
> I would appreciate it if you ran those tests. It doesn't bother me nearly 
> as much that they are proprietary tests. At least we'll know that something 
> executed correctly with the other protocols! Improving the coverage of the 
> regression tests is hugely outside of the scope for this patch.
> 
> I'd still like to hear what others think about this problem in the longer 
> term.
> 
> Andreas Hansson wrote:
> Another potential issue: The queue of requests that has been created, 
> does it officially need to be visible to any functional access? In other 
> words, has it "happened" yet? For the queued ports we have functions to query 
> the queued packets on a functional access, but that does not seem to be 
> present in the patch.
> 
> Brad Beckmann wrote:
> I think Michael is a bit unsure how to move this patch forward in a 
> reasonable way.  Here are a couple things to consider:
> 
> - Jason, another way Michael could have approached this patch is simply 
> provided the changes to the DMASequencer and not touched the public 
> protocols.  Limiting these DMA controllers to only a single outstanding 
> request is obviously a big bottleneck, but we don't use these protocols at 
> AMD.  Michael really went beyond what was necessary here.  If he tests the 
> basically functionality of the public protocol changes, I think that is 
> enough.  We should minimize the burden for performance fixes to the public 
> protocols.
> - Andreas, in many of your recent Ruby code reviews, you've mentioned 
> concerns with functional accesses.  Perhaps we should arrange a separate 
> thread on the topic and clarify the current state of Ruby functional 
> accesses, as well as discuss your goals.  I'm pretty sure this patch is 
> orthogonal to functional accesses.  It is simply allowing multiple DMA 
> requests to be processed by the public DMA controllers.

I think this change is great, I would like to see it pushed in. I agree that 
these changes are needed to get reasonable DMA performance. 

I agree that's enough to just test the basic functionality with the public 
protocols. As long as these protocols have all been compiled, and any workload 
that exercises DMA is run on the protocol, I'm happy.

In the past, there have been changes to Ruby protocols that weren't tested at 
all. Then, sometimes months later, users (i.e., people down the hall from me) 
have noticed that the protocols were broken, in some cases they didn't even 
compile! Digging back through hundreds of changes to find out what broke the 
protocol is incredibly time consuming, even with hg bisect. IMO, we should 
strucure our code requirements to avoid this.

For now, I'm perfectly happy with just asking the question "Did you test these 
changes?" and the reviewee replying "Yes". In the future we can work on the 
regression test coverage.

I agree that functional access is out of the scope here (it's already broken in 
Ruby). It is something we probably should do at some point, 

Re: [gem5-dev] Review Request 3591: ruby: Allow multiple outstanding DMA requests

[Brad Beckmann]

> On Sept. 1, 2016, 3:33 p.m., Jason Lowe-Power wrote:
> > What testing did you perform to make sure all of the protocols were 
> > modified correctly?
> > 
> > Most of these changes seem reasonable to me, but I know from experience 
> > that even when the SLICC changes seem like they are right, if they aren't 
> > tested carefully there's almost always bugs.
> 
> Michael LeBeane wrote:
> The sequencer changes have been tested pretty thoroughly in a custom 
> protocol; the public SLICC files only with the regression tester.  I'm not 
> sure how much coverage that provides for DMA other than checking if it 
> compiles.
> 
> Jason Lowe-Power wrote:
> I'm not sure what to do about this. Maybe others in the community will 
> speak up ;).
> 
> I don't feel comfortable pushing a patch with code that we know hasn't 
> been tested at all. Specifically with Ruby/SLICC, this has bitten me before. 
> I've updated gem5 and all of sudden my simluations are broken because someone 
> changed a protocol without testing it. IMO, code needs to be tested at least 
> somewhat before it's pushed into the mainline.
> 
> However, I also understand that there isn't any testing infrastructure 
> for most of the protocols, and we can't ask you to solve that problem before 
> pushing the patch in.
> 
> Do others have thoughts on this (reoccurring) problem? 
> 
> For this specific patch, can you run your workload that use DMA with 
> protocols other than your internal protocol?
> 
> Michael LeBeane wrote:
> It would take some effort, but I do have some DMA intensive networking 
> benchmarks that should be able to run over the public protocols.  I wouldn't 
> be able to share these or add them to the regression tester (they are 
> proprietary).
> 
> I know that doesn't help at all with the more general problem of poor 
> tester coverage, but would that be an acceptable solution for this patch?
> 
> Jason Lowe-Power wrote:
> I would appreciate it if you ran those tests. It doesn't bother me nearly 
> as much that they are proprietary tests. At least we'll know that something 
> executed correctly with the other protocols! Improving the coverage of the 
> regression tests is hugely outside of the scope for this patch.
> 
> I'd still like to hear what others think about this problem in the longer 
> term.
> 
> Andreas Hansson wrote:
> Another potential issue: The queue of requests that has been created, 
> does it officially need to be visible to any functional access? In other 
> words, has it "happened" yet? For the queued ports we have functions to query 
> the queued packets on a functional access, but that does not seem to be 
> present in the patch.

I think Michael is a bit unsure how to move this patch forward in a reasonable 
way.  Here are a couple things to consider:

- Jason, another way Michael could have approached this patch is simply 
provided the changes to the DMASequencer and not touched the public protocols.  
Limiting these DMA controllers to only a single outstanding request is 
obviously a big bottleneck, but we don't use these protocols at AMD.  Michael 
really went beyond what was necessary here.  If he tests the basically 
functionality of the public protocol changes, I think that is enough.  We 
should minimize the burden for performance fixes to the public protocols.
- Andreas, in many of your recent Ruby code reviews, you've mentioned concerns 
with functional accesses.  Perhaps we should arrange a separate thread on the 
topic and clarify the current state of Ruby functional accesses, as well as 
discuss your goals.  I'm pretty sure this patch is orthogonal to functional 
accesses.  It is simply allowing multiple DMA requests to be processed by the 
public DMA controllers.


- Brad


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3591/#review8698
---


On Aug. 30, 2016, 3:54 p.m., Michael LeBeane wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3591/
> ---
> 
> (Updated Aug. 30, 2016, 3:54 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11557:5d6fcf14c77e
> ---
> ruby: Allow multiple outstanding DMA requests
> DMA sequencers and protocols can currently only issue one DMA access at a 
> time.
> This patch implements the necessary functionality to support multiple
> outstanding DMA requests in Ruby.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/Sequencer.py 985d9b9a68bf20e22ba65f7398dde0193e6ca076 
>   src/mem/ruby/system/DMASequencer.hh 
> 985d9b9a68bf20e22ba65f7398dde0193e6ca076 
>   src/mem/ruby/system/DMASequencer.cc 
> 

Re: [gem5-dev] Review Request 3595: dev: Add m5 op to toggle synchronization for dist-gem5.

[Gabor Dozsa]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3595/#review8713
---


I like the idea of starting the sync on a pseudo op very much. I cannot see the 
usefulness of stopping the sync after it started though.  Do you have a use 
case in mind?

I have a few comments below (mainly minor nits). 

However, I think there is also a basic issue with the CPU suspend approach. A 
CPU can wake up whenever there is an interrupt or even a snoop request. That 
should be taken care of somehow I assume.


src/dev/net/dist_iface.hh (line 461)


The type should be bool. 

Minor nit: the name could be changed to something like 
"syncStartOnPseudoOp" to reflect the meaning better.



src/dev/net/dist_iface.hh (line 627)


Minor nit: could you rename this method to "toggleSync()" or similar? That 
would better describe the functionality. The word "switch" ususally refers to 
the network switch model in the dist-gem5 context so it is a bit confusing here.



src/dev/net/dist_iface.cc (line 71)


This change effectively disables the use of the start_tick parameter. It is 
because 'nextAt' is overwritten in SyncEvent::start() by the max tick of all 
participating gem5 - which will be 0 at the first global barrier (if we do not 
start the sync on pseudo op).   

However, I think the pseudo op is a much better way to defer the sync 
start. Could you just remove the 'start_tick' option altogether?



src/dev/net/dist_iface.cc (line 830)


Cannot another active thread hit another stop-sync pesudo op while this 
thread is still suspended? Maybe all active threads should be suspended here?


- Gabor Dozsa


On Aug. 4, 2016, 4:51 p.m., Michael LeBeane wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3595/
> ---
> 
> (Updated Aug. 4, 2016, 4:51 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11561:1414a40eb1e2
> ---
> dev: Add m5 op to toggle synchronization for dist-gem5.
> This patch adds the ability for an application to request dist-gem5 to begin/
> end synchronization using an m5 op.  When toggling on sync, all nodes agree on
> the next sync point based on the maximum of all nodes' ticks.  CPUs are
> suspended until the sync point to avoid sending network messages until sync 
> has
> been enabled.  Toggling off sync acts like a global execution barrier, where
> all CPUs are disabled until every node reaches the toggle off point.  This
> avoids tricky situations such as one node hitting a toggle off followed by a
> toggle on before the other nodes hit the first toggle off.
> 
> 
> Diffs
> -
> 
>   configs/common/Options.py 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/arch/x86/isa/decoder/two_byte_opcodes.isa 
> 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/Ethernet.py 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/dist_etherlink.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/dist_iface.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/dist_iface.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/dist_packet.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/tcp_iface.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/dev/net/tcp_iface.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/sim/pseudo_inst.hh 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   src/sim/pseudo_inst.cc 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   util/m5/m5op.h 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   util/m5/m5op_x86.S 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
>   util/m5/m5ops.h 91f58918a76abf1a1dedcaa70a9b95789da7b88c 
> 
> Diff: http://reviews.gem5.org/r/3595/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Michael LeBeane
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Architecture of gem5

[Boris Shingarov/Employee/LW-US]

I remember back when I was using Simics, there were these things called "Linux 
process trackers" that did exactly that.  
It  was all written in Python, and there was a point when various  
processor-specific trackers got simplified / pulled together into one  generic 
tracker in which only the truly ISA-dependent knowledge was  pushed down to 
subclasses like x86_ops/ppc_ops etc., which would  override methods like 
"syscall_num()" according with passing that num in  eax vs r0; or overriding 
"current_task()" according to the struct being  kept on the kernel stack vs 
pointed by sprg3, etc.
It would be  extremely interesting to have similar functionality in gem5, and I 
have  even thought about writing something like that myself, but I don't know  
much about the infrastructure that would allow one to hook up such  Python 
scripts to haps like "memory access breakpoint" or "interrupt" or  "user/kernel 
mode change" easily and even on-the-fly in the middle of  debugging the kernel. 
 If someone could provide an initial explanation  of what mechanisms are there 
beyond using Python for initial  configuration, it would serve as a push 
forward at least for me.

-"gem5-dev"  wrote: -
To: gem5 Developer List 
From: "Potter, Brandon" 
Sent by: "gem5-dev" 
Date: 09/08/2016 07:26PM
Subject: Re: [gem5-dev] Architecture of gem5

With full-system mode, you can do kernel introspection. The kernel resides in 
the simulated memory which you have complete control over; you can do whatever 
you want to do with it. The kernel is what is responsible for managing the 
processes and their memory so if you want interesting kernel-level information, 
you might look into reading the kernel's physical memory directly.

With complete access to the full memory layout, you can play tricks with the 
physical memory and OS symbols to access structures, namely task_struct and 
mm_struct. It's difficult to do this and requires a bit of trial and error to 
figure out which symbols the kernel exposes to allow you to do this, but it is 
possible. The trick is to read the hex values from physical memory and compare 
them with the Linux kernel source; you can reason about which fields are 
pointers and which have values that are defined in the source. It just takes 
work to puzzle out the rest. I did this once with Simics so it is possible, but 
it's time consuming.

If you obtain access to the task_struct list, you can get access to the 
mm_struct which give you the full memory layout for each process. With the full 
memory layout, you can discern which areas of each process' virtual address 
space are mapped and which physical frames (in the simulated memory) correspond 
to those virtual address. In this way, you can get both the virtual and 
physical addresses of addresses for any process.

As Jason mentioned, you can use /proc/{some_pid}/maps to figure out the virtual 
address ranges that are mapped (at a specific point in the execution of that 
process). Furthermore, you can use pagemap to figure out what the physical 
address is. The catch with using these methods is that the simulator has to be 
running and the process that you're interested in examining has to be running 
to read the files (because the maps and pagemaps features are pseudo files). If 
you have a short-running process, you typically have to add a `while(1)` loop 
into the application to figure out the mappings.

Also as Jason mentioned on X86, you can examine the ring level that the CPU is 
in to figure out if the kernel is executing or if the process is running in 
userspace; if you don't understand what we're talking about, read 
http://duartes.org/gustavo/blog/post/cpu-rings-privilege-and-protection/. You 
can examine the segmentation registers and figure out at any given time what's 
going on. (If you don't know much about memory, I'd read the rest of his blog 
posts on the topic as well. It's a nice summary of Linux memory for the 
uninitiated.) Also, userspace processes should not have access to kernel space 
data. Linux draws a line in the virtual memory sand for different architectures 
to specify what is "kernel space" and what is "user space". With X86-64, 48 
bits [47...0] are used for virtual addresses. (The 47th bit gets sign-extended 
to the 63rd bit so that all of the intervening bits don't really matter.) If 
the sign extended bits are 1s, then the accesses are going into kernel space 
and you can be reasonably sure that the kernel is executing. So, the fool proof 
method is the CPL level in the code segment register, but you can sometimes 
tell by the accesses if the kernel is running or not. If you want to learn 
about memory in Linux, the canonical document, at least in my mind is: 
https://www.kernel.org/doc/gorman/. (Although, the book is a bit dated.)

If you're looking to track a specific process in X86, you should be able to 
monitor the CR3 register to verify that the correct process is 

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

[Cron Daemon]

* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing: passed.
 * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: 
passed.* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: 
passed.
 * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing: passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 passed.
* build/ALPHA/tests/opt/quick/se/30.eon/alpha/tru64/simple-atomic: passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing: 
passed.
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic: passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing: passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level:
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level:
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level:
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level:
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory:
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory:
 passed.* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory:
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory:
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token:
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token:
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token:
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token:
 passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 passed.* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: 
passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter: passed.
* build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem: passed.
*