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.
The m5ops assembly library contains a lot of repetitive code. This
changeset adds two macros, FOREACH_M5OP and FOREACH_M5_ANNOTATION, to
m5ops.h that simplify architecture-specific implementations. The ARM
and ARMv8 m5op implementations have been updated to use the new
macros.
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
This patch adds methods in KvmCPU model to handle KVM exits caused by syscall
instructions and page faults. These types of exits will be encountered if
KvmCPU is run in SE mode.
1) fixes a typo for clean target libgemOpJni.so -> libgem5OpJni.so
2) addes jni_gem5Op.h to clean since it is added during make
3) links the m5 utility statically since it won't work on some images otherwise
Note: AArch64 and AArch32 interworking is not supported. If you use an AArch64
kernel you are restricted to AArch64 user-mode binaries. This will be addressed
in a later patch.
Note: Virtualization is only supported in AArch32 mode. This will also be fixed
in a later patch.
Contributors:
Giacomo Gabrielli (TrustZone, LPAE, system-level AArch64, AArch64 NEON, validation)
Thomas Grocutt (AArch32 Virtualization, AArch64 FP, validation)
Mbou Eyole (AArch64 NEON, validation)
Ali Saidi (AArch64 Linux support, code integration, validation)
Edmund Grimley-Evans (AArch64 FP)
William Wang (AArch64 Linux support)
Rene De Jong (AArch64 Linux support, performance opt.)
Matt Horsnell (AArch64 MP, validation)
Matt Evans (device models, code integration, validation)
Chris Adeniyi-Jones (AArch64 syscall-emulation)
Prakash Ramrakhyani (validation)
Dam Sunwoo (validation)
Chander Sudanthi (validation)
Stephan Diestelhorst (validation)
Andreas Hansson (code integration, performance opt.)
Eric Van Hensbergen (performance opt.)
Gabe Black
Changes to make m5ops work under virtualization seemed to break them working
with non-virtualized systems and the recently added m5 fail command makes
the m5op binary not compile. For now remove the code for virtualization.
In order to support m5ops in virtualized environments, we need to use
a memory mapped interface. This changeset adds support for that by
reserving 0xFFFF0000-0xFFFFFFFF and mapping those to the generic IPR
interface for m5ops. The mapping is done in the
X86ISA::TLB::finalizePhysical() which means that it just works for all
of the CPU models, including virtualized ones.
Using arm-linux-gnueabi-gcc 4.7.3-1ubuntu1 on Ubuntu 13.04 to compiled
the m5 binary yields the error:
m5op_arm.S: Assembler messages:
m5op_arm.S:85: Error: selected processor does not support ARM mode `bxj lr'
For each of of the SIMPLE_OPs. Apparently, this compiler doesn't like the
interworking of these code types for the default arch. Adding -march=armv7-a
makes it compile. Another alternative that I found to work is replacing the
bxj lr instruction with mov pc, lr, but I don't know how that affects the
KVM stuff and if bxj is needed.
Changeset 5ca6098b9560 accidentally broke the m5 utility. This
changeset adds the missing co-processor call used to trigger the
pseudo-op in ARM mode and fixes an alignment issue that caused some
pseudo-ops to leave thumb mode.
This changeset adds support for m5 pseudo-ops when running in
kvm-mode. Unfortunately, we can't trap the normal gem5 co-processor
entry in KVM (it doesn't seem to be possible to trap accesses to
non-existing co-processors). We therefore use BZJ instructions to
cause a trap from virtualized mode into gem5. The BZJ instruction is
becomes a normal branch to the gem5 fallback code when running in
simulated mode, which means that this patch does not need to change
the ARM ISA-specific code.
Note: This requires a patched host kernel.
Changeset 02321b16685f added m5_writefile to m5op_x86.S a second time,
which causes a compilation error on when compiling for x86. This
changeset reverts that changeset and fixes the error.
Used as a command in full-system scripts helps the user ensure the benchmarks have finished successfully.
For example, one can use:
/path/to/benchmark args || /sbin/m5 fail 1
and thus ensure gem5 will exit with an error if the benchmark fails.
The number of arguments specified when calling parse_int_args() in
do_exit() is incorrect. This leads to stack corruption since it causes
writes past the end of the ints array.
Updated the util/m5/Makefile.arm so that m5op_arm.S is used to create
a static library - libm5.a. Allowing users to insert m5
psuedo-instructions into their applications for fine-grained
checkpointing, switching cpus or dumping statistics. e.g.
#include <m5op.h>
void foo(){
...
m5_reset_stats(<delay>,<period>)
m5_work_begin(<workid>,<threadid>);
...
m5_work_end(<workid>,<threadid>);
m5_dump_stats(<delay>,<period>);
}
Usage: m5 writefile <filename>
File will be created in the gem5 output folder with the identical filename.
Implementation is largely based on the existing "readfile" functionality.
Currently does not support exporting of folders.
These ops allow gem5 ops to be called from within java programs like the following:
import jni.gem5Op;
public class HelloWorld {
public static void main(String[] args) {
gem5Op gem5 = new gem5Op();
System.out.println("Rpns0:" + gem5.rpns());
System.out.println("Rpns1:" + gem5.rpns());
}
static {
System.loadLibrary("gem5OpJni");
}
}
When building you need to make sure classpath include gem5OpJni.jar:
javac -classpath $CLASSPATH:/path/to/gem5OpJni.jar HelloWorld.java
and when running you need to make sure both the java and library path are set:
java -classpath $CLASSPATH:/path/to/gem5OpJni.jar -Djava.library.path=/path/to/libgem5OpJni.so HelloWorld
- insert warnings for deprecated m5ops
- reserve opcodes for Ali's stuff
- remove code for stuff that has been deprecated forever
- simplify m5op_alpha
src/arch/sparc/isa/decoder.isa:
add readfile and break to sparc decoder
src/arch/sparc/isa/operands.isa:
fix O0-O5 operands registers
util/m5/Makefile.sparc:
Make sparc makefile compile a 64bit binary
util/m5/m5.c:
readfile was in here twice, once will be sufficient I think
util/m5/m5op_sparc.S:
implement readfile and debugbreak
--HG--
extra : convert_revision : 139b3f480ee6342b37b5642e072c8486d91a3944
util/m5/Makefile.alpha:
Clean up to make it a bit easier to muck with
util/m5/Makefile.alpha:
Make the makefile more reasonable
util/m5/Makefile.alpha:
Remove authors from copyright.
util/m5/Makefile.alpha:
Updated Authors from bk prs info
util/m5/Makefile.alpha:
bk cp Makefile Makefile.alpha
src/arch/sparc/tlb.cc:
Clean up the cache code a little bit and make sure the uncacbale bit is set when appropriate
src/arch/alpha/isa/decoder.isa:
src/sim/pseudo_inst.cc:
src/sim/pseudo_inst.hh:
Rename AlphaPseudo -> PseudoInst since it's all generic
src/arch/sparc/isa/bitfields.isa:
src/arch/sparc/isa/decoder.isa:
src/arch/sparc/isa/includes.isa:
src/arch/sparc/isa/operands.isa:
Add support for pseudo instructions in sparc
util/m5/Makefile.alpha:
util/m5/Makefile.sparc:
split off alpha make file and sparc make file for m5 app
util/m5/m5.c:
ivle and ivlb aren't used anymore
util/m5/m5op.h:
stdint seems like a more generic better fit here
util/m5/m5op_alpha.S:
move the op ids into their own header file since we can share them between sparc and alpha
--HG--
rename : util/m5/Makefile => util/m5/Makefile.sparc
rename : util/m5/m5op.S => util/m5/m5op_alpha.S
extra : convert_revision : 490ba2e8b8bc6e28bfc009cedec6b686b28e7834
