Re: [gem5-dev] Review Request 3583: syscall_emul: Added getdents and getdents64 syscalls

2016-08-09 Thread Brandon Potter 

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


Hi Nicolas, thanks for the contribution. Couple of things before you commit 
this.


src/sim/syscall_emul.hh (line 308)


alignment should be under the 'S' in "SyscallDesc"



src/sim/syscall_emul.hh (line 312)


alignment



src/sim/syscall_emul.cc (line 355)


Please rename fd to sim_fd. It gets confusing over time if the distinction 
isn't explicit especially in more complicated functions. I've seen at least one 
bug that was caused by this type of naming.



src/sim/syscall_emul.cc (line 356)


This should not be an assert here. I think the correct thing to do here is 
instead "if(fd < 0) {return -EBADF;}".

The point is that the application is free to pass in bad file descriptors 
to the kernel. The kernel's job is to reject the file descriptor and return an 
errno to the application. It's not the kernel's job to kill the process for 
passing in a bad file descriptor.



src/sim/syscall_emul.cc (line 357)


Local variables are supposed to be lower case and seperated by underscores 
(instead of camel case).

http://www.m5sim.org/Coding_Style



src/sim/syscall_emul.cc (line 359)


variable name



src/sim/syscall_emul.cc (line 361)


save errno to a local variable after the system call



src/sim/syscall_emul.cc (line 363)


space between if keyword and paren



src/sim/syscall_emul.cc (line 372)


add a conditional return here if the sim_fd is bad



src/sim/syscall_emul.cc (line 373)


rename fd to sim_fd



src/sim/syscall_emul.cc (line 374)


name



src/sim/syscall_emul.cc (line 376)


name



src/sim/syscall_emul.cc (line 378)


You should save the errno value into a local variable immediately after a 
real system call if you have intervening code between the system call and the 
code.

Otherwise, the errno value might get clobbered before you return it.



src/sim/syscall_emul.cc (line 380)


space


- Brandon Potter


On Aug. 8, 2016, 9:18 a.m., Nicolas Derumigny wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3583/
> ---
> 
> (Updated Aug. 8, 2016, 9:18 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> syscall_emul: Added getdents and getdents64 syscalls
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/process.cc ba45735a726a 
>   src/sim/syscall_emul.hh ba45735a726a 
>   src/sim/syscall_emul.cc ba45735a726a 
> 
> Diff: http://reviews.gem5.org/r/3583/diff/
> 
> 
> Testing
> ---
> 
> Works with readdir() wrapper, tested with CERE codelets 
> (https://github.com/benchmark-subsetting/cere).
> 
> 
> Thanks,
> 
> Nicolas Derumigny
> 
>

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

Re: [gem5-dev] Review Request 3580: cpu, mem, sim: Enable KVM support for Ruby

2016-08-09 Thread Brandon Potter 


> On Aug. 5, 2016, 7:15 a.m., Andreas Hansson wrote:
> > I see how this works as a stop gap, but ultimately I would like to push for 
> > the removal of the shadow memory as the first option. Is it really that 
> > much effort?
> 
> David Hashe wrote:
> I'm not personally familiar enough with why the shadow memory is needed 
> to be able to say how much effort it would take to remove, but I believe so.
> 
> Brandon Potter wrote:
> Providing background since some might not be familiar with the problem.
> 
> __The following links are relevant:__
> http://reviews.gem5.org/r/2466 (Joel Hestness' response to Andreas 
> Hansson)
> http://reviews.gem5.org/r/2627 (Joel Hestness' comment)
> http://reviews.gem5.org/r/3580 (Andreas Hansson's comment)
> 
> https://groups.google.com/forum/#!msg/gem5-gpu-dev/hjMJs_bAwlY/tE05yRQfJysJ 
> (Joel Hestness’ comment)
> 
> __Why does Ruby need a shadow copy?__
> 
> Ruby needs the shadow copy to allow it to do functional accesses in 
> situations where it would normally fail. Functional accesses are generated by 
> system calls or by devices to do functional loading and storing to hack 
> around deficiencies in the device model or runtime.
> 
> __What is a functional access?__
> 
> A functional access is a memory access that immediately resolves in the 
> memory system. Typically, this involves updating the data value of the memory 
> location without generating any events that go into the event queue. The 
> result is that the memory values appear to have been updated magically 
> without ever creating the events that it would have needed to create if it 
> was operating in the normal manner.
> 
> __What's different about functional accesses compared with timing 
> accesses?__
> 
> The difference is that functional accesses must complete immediately 
> before returning control back over to the simulation. For example, system 
> calls are executed in an X86 system when the processor executes either 'int 
> 0x80' or 'syscall'. In SE mode, the system call invocation and all of the 
> resulting loads and stores must be completed by the time that we return 
> control back to the simulated process. That single 'syscall' instruction that 
> the processor executes is supposed to represent an entire set of 
> instructions, many of them necessary loads and stores, that would have 
> executed if we were running the code in a real system with an actual kernel.
> 
> Timing accesses, on the other hand, are sent through the cache hierarchy 
> and represent what would happen in a "real" system. For timing accesses, the 
> processor creates events that get put into the event queue and are resolved 
> at specific ticks according to the memory model associated with the 
> simulation. Each memory event can generate subsequent events which may or may 
> not modify the cache state and memory state of the simulated system.
> 
> __Why can't Ruby handle functional accesses without the shadow copy?__
> 
> Well it could handle function accesses without the shadow copy, but it's 
> difficult to implement properly for most protocols. The shadow copy has been 
> considered to be an acceptable crutch to allow protocol writers to avoid the 
> complexities associated with verifying that their protocol is data correct.
> 
> Consider the following case: a read request comes into an L1 cache and is 
> about to evict a cache line to be sent to a downstream L2 cache. The eviction 
> is represented by a series of state transitions in Ruby to handle moving the 
> stale data out of the L1 into the L2 or possibly a temporary buffer before 
> copying the new data into the L1 cache. There may be several intermediate 
> states needed to complete transition which are termed transient states. While 
> the cache line’s state machine is in a transient state, data cannot be read 
> or written to the cache line. (Ruby has an assertion in the code to protect 
> against reads on lines that must be due to some of the data being "busy".) 
> The asserts were added because the evicted, old data likely resides in some 
> temporary data structure(s) which are likely not easy to access and update 
> (i.e. MSHR, write buffer, message buffer, request packets, etc.). That 
> doesn’t mean that it’s conceptually impossible to update all of this 
> temporary data; it’s just difficult to do in most cases.
> 
> __How does the shadow copy solve the problem?__
> 
> The "--access-backing-store" option solves the problem by caching data in 
> a shadow copy of the system memory. __All functional accesses are sent to 
> this shadow copy instead of being directed to the normal, default system 
> memory. Also, hit callbacks from the memory slave ports (which belong to the 
> sequencers that created the request) will write (or read) data into (from) 
> the shadow copy during the hit callback. If I am not mistaken, the hit 
>

Re: [gem5-dev] Review Request 3580: cpu, mem, sim: Enable KVM support for Ruby

2016-08-09 Thread Brandon Potter 


> On Aug. 5, 2016, 7:15 a.m., Andreas Hansson wrote:
> > I see how this works as a stop gap, but ultimately I would like to push for 
> > the removal of the shadow memory as the first option. Is it really that 
> > much effort?
> 
> David Hashe wrote:
> I'm not personally familiar enough with why the shadow memory is needed 
> to be able to say how much effort it would take to remove, but I believe so.

Providing background since some might not be familiar with the problem.

__The following links are relevant:__
http://reviews.gem5.org/r/2466 (Joel Hestness' response to Andreas Hansson)
http://reviews.gem5.org/r/2627 (Joel Hestness' comment)
http://reviews.gem5.org/r/3580 (Andreas Hansson's comment)
https://groups.google.com/forum/#!msg/gem5-gpu-dev/hjMJs_bAwlY/tE05yRQfJysJ 
(Joel Hestness’ comment)

__Why does Ruby need a shadow copy?__

Ruby needs the shadow copy to allow it to do functional accesses in situations 
where it would normally fail. Functional accesses are generated by system calls 
or by devices to do functional loading and storing to hack around deficiencies 
in the device model or runtime.

__What is a functional access?__

A functional access is a memory access that immediately resolves in the memory 
system. Typically, this involves updating the data value of the memory location 
without generating any events that go into the event queue. The result is that 
the memory values appear to have been updated magically without ever creating 
the events that it would have needed to create if it was operating in the 
normal manner.

__What's different about functional accesses compared with timing accesses?__

The difference is that functional accesses must complete immediately before 
returning control back over to the simulation. For example, system calls are 
executed in an X86 system when the processor executes either 'int 0x80' or 
'syscall'. In SE mode, the system call invocation and all of the resulting 
loads and stores must be completed by the time that we return control back to 
the simulated process. That single 'syscall' instruction that the processor 
executes is supposed to represent an entire set of instructions, many of them 
necessary loads and stores, that would have executed if we were running the 
code in a real system with an actual kernel.

Timing accesses, on the other hand, are sent through the cache hierarchy and 
represent what would happen in a "real" system. For timing accesses, the 
processor creates events that get put into the event queue and are resolved at 
specific ticks according to the memory model associated with the simulation. 
Each memory event can generate subsequent events which may or may not modify 
the cache state and memory state of the simulated system.

__Why can't Ruby handle functional accesses without the shadow copy?__

Well it could handle function accesses without the shadow copy, but it's 
difficult to implement properly for most protocols. The shadow copy has been 
considered to be an acceptable crutch to allow protocol writers to avoid the 
complexities associated with verifying that their protocol is data correct.

Consider the following case: a read request comes into an L1 cache and is about 
to evict a cache line to be sent to a downstream L2 cache. The eviction is 
represented by a series of state transitions in Ruby to handle moving the stale 
data out of the L1 into the L2 or possibly a temporary buffer before copying 
the new data into the L1 cache. There may be several intermediate states needed 
to complete transition which are termed transient states. While the cache 
line’s state machine is in a transient state, data cannot be read or written to 
the cache line. (Ruby has an assertion in the code to protect against reads on 
lines that must be due to some of the data being "busy".) The asserts were 
added because the evicted, old data likely resides in some temporary data 
structure(s) which are likely not easy to access and update (i.e. MSHR, write 
buffer, message buffer, request packets, etc.). That doesn’t mean that it’s 
conceptually impossible to update all of this temporary data; it’s just 
difficult to do in most cases.

__How does the shadow copy solve the problem?__

The "--access-backing-store" option solves the problem by caching data in a 
shadow copy of the system memory. __All functional accesses are sent to this 
shadow copy instead of being directed to the normal, default system memory. 
Also, hit callbacks from the memory slave ports (which belong to the sequencers 
that created the request) will write (or read) data into (from) the shadow copy 
during the hit callback. If I am not mistaken, the hit callback on the memory 
slave port is equivalent to an L1 hit meaning that the request completed 
traversing the cache subsystem. In traversing the cache subsystem, the request 
did touch the default memory through normal behavior, but any returning 
information carried by the packet will be discarded in

Re: [gem5-dev] Review Request 3577: arm, config: Add initial support for Ruby

2016-08-09 Thread Andreas Sandberg 


> On July 25, 2016, 3:32 p.m., Jason Lowe-Power wrote:
> > Nice to see ARM thinking about Ruby support! Should we enable some tests 
> > for it now?

Not yet. This is still extremely experimental and there are a few known issues 
with it. We have university partners looking at them, so this will hopefully 
change soon.


- Andreas


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


On July 22, 2016, 4:06 p.m., Andreas Sandberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3577/
> ---
> 
> (Updated July 22, 2016, 4:06 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11575:13ce69703444
> ---
> arm, config: Add initial support for Ruby
> 
> Add initial support for creating an ARM system with a Ruby-based
> memory system. This support is currently experimental and limited to
> the new VExpress_GEM5_V1 platform.
> 
> Change-Id: I36baeb68b0d891e34ea46aafe17b5e55217b4bfa
> Signed-off-by: Andreas Sandberg 
> Reviewed-by: Nikos Nikoleris 
> 
> 
> Diffs
> -
> 
>   configs/common/FSConfig.py 4aac82f10951 
>   configs/example/fs.py 4aac82f10951 
> 
> Diff: http://reviews.gem5.org/r/3577/diff/
> 
> 
> Testing
> ---
> 
> Boots a single-core ARM system using the VExpress_GEM5_V1 platform. Ruby 
> support is still incomplete and multi-core systems are known to be broken.
> 
> 
> Thanks,
> 
> Andreas Sandberg
> 
>

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

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

2016-08-09 Thread Cron Daemon 
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby: 
passed.* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
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-atomic: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby: 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 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/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/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/se/00.hello/alpha/linux/o3-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic: 
passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic: passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-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/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level:
 passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing: 
passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/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/tru64/simple-timing-ruby-MOESI_CMP_directory:
 passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing: passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory:
 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.
* 
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/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/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-timing: 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-ruby: 
passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level:
 passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic: passed.
*