Re: [gem5-dev] Review Request 3680: syscall_emul: [patch 13/22] add system call retry capability
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3680/#review9436 --- Ship it! Ship It! - Tony Gutierrez On Feb. 17, 2017, 2:03 p.m., Brandon Potter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3680/ > --- > > (Updated Feb. 17, 2017, 2:03 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > --- > > Changeset 11859:2f88471df39a > --- > syscall_emul: [patch 13/22] add system call retry capability > > This changeset adds functionality that allows system calls to retry without > affecting thread context state such as the program counter or register values > for the associated thread context (when system calls return with a retry > fault). > > This functionality is needed to solve problems with blocking system calls > in multi-process or multi-threaded simulations where information is passed > between processes/threads. Blocking system calls can cause deadlock because > the simulator itself is single threaded. There is only a single thread > servicing the event queue which can cause deadlock if the thread hits a > blocking system call instruction. > > To illustrate the problem, consider two processes using the producer/consumer > sharing model. The processes can use file descriptors and the read and write > calls to pass information to one another. If the consumer calls the blocking > read system call before the producer has produced anything, the call will > block the event queue (while executing the system call instruction) and > deadlock the simulation. > > The solution implemented in this changeset is to recognize that the system > calls will block and then generate a special retry fault. The fault will > be sent back up through the function call chain until it is exposed to the > cpu model's pipeline where the fault becomes visible. The fault will trigger > the cpu model to replay the instruction at a future tick where the call has > a chance to succeed without actually going into a blocking state. > > In subsequent patches, we recognize that a syscall will block by calling a > non-blocking poll (from inside the system call implementation) and checking > for events. When events show up during the poll, it signifies that the call > would not have blocked and the syscall is allowed to proceed (calling an > underlying host system call if necessary). If no events are returned from the > poll, we generate the fault and try the instruction for the thread context > at a distant tick. Note that retrying every tick is not efficient. > > As an aside, the simulator has some multi-threading support for the event > queue, but it is not used by default and needs work. Even if the event queue > was completely multi-threaded, meaning that there is a hardware thread on > the host servicing a single simulator thread contexts with a 1:1 mapping > between them, it's still possible to run into deadlock due to the event queue > barriers on quantum boundaries. The solution of replaying at a later tick > is the simplest solution and solves the problem generally. > > > Diffs > - > > src/arch/alpha/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/arm/faults.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/arm/faults.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/mips/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/power/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/riscv/faults.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/sparc/linux/process.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/sparc/linux/process.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/isa/decoder/one_byte_opcodes.isa > f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/isa/decoder/two_byte_opcodes.isa > f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/process.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/process.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/pseudo_inst.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/BaseCPU.py f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/base.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/base.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/checker/cpu.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/checker/thread_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/exec_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/minor/exec_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/commit.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 >
Re: [gem5-dev] Review Request 3680: syscall_emul: [patch 13/22] add system call retry capability
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3680/ --- (Updated Feb. 17, 2017, 10:03 p.m.) Review request for Default. Repository: gem5 Description (updated) --- Changeset 11859:2f88471df39a --- syscall_emul: [patch 13/22] add system call retry capability This changeset adds functionality that allows system calls to retry without affecting thread context state such as the program counter or register values for the associated thread context (when system calls return with a retry fault). This functionality is needed to solve problems with blocking system calls in multi-process or multi-threaded simulations where information is passed between processes/threads. Blocking system calls can cause deadlock because the simulator itself is single threaded. There is only a single thread servicing the event queue which can cause deadlock if the thread hits a blocking system call instruction. To illustrate the problem, consider two processes using the producer/consumer sharing model. The processes can use file descriptors and the read and write calls to pass information to one another. If the consumer calls the blocking read system call before the producer has produced anything, the call will block the event queue (while executing the system call instruction) and deadlock the simulation. The solution implemented in this changeset is to recognize that the system calls will block and then generate a special retry fault. The fault will be sent back up through the function call chain until it is exposed to the cpu model's pipeline where the fault becomes visible. The fault will trigger the cpu model to replay the instruction at a future tick where the call has a chance to succeed without actually going into a blocking state. In subsequent patches, we recognize that a syscall will block by calling a non-blocking poll (from inside the system call implementation) and checking for events. When events show up during the poll, it signifies that the call would not have blocked and the syscall is allowed to proceed (calling an underlying host system call if necessary). If no events are returned from the poll, we generate the fault and try the instruction for the thread context at a distant tick. Note that retrying every tick is not efficient. As an aside, the simulator has some multi-threading support for the event queue, but it is not used by default and needs work. Even if the event queue was completely multi-threaded, meaning that there is a hardware thread on the host servicing a single simulator thread contexts with a 1:1 mapping between them, it's still possible to run into deadlock due to the event queue barriers on quantum boundaries. The solution of replaying at a later tick is the simplest solution and solves the problem generally. Diffs (updated) - src/arch/alpha/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/arm/faults.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/arm/faults.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/mips/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/power/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/riscv/faults.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/sparc/linux/process.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/sparc/linux/process.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/x86/isa/decoder/one_byte_opcodes.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/x86/isa/decoder/two_byte_opcodes.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/x86/process.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/x86/process.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/arch/x86/pseudo_inst.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/BaseCPU.py f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/base.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/base.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/checker/cpu.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/checker/thread_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/exec_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/minor/exec_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/o3/commit.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/o3/commit_impl.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/o3/cpu.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/o3/cpu.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/o3/dyn_inst.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/o3/dyn_inst_impl.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/o3/thread_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 src/cpu/o3/thread_state.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55
Re: [gem5-dev] Review Request 3680: syscall_emul: [patch 13/22] add system call retry capability
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3680/#review9066 --- I think the commit message could be a bit clearer about the problem this patch is attempting to solve. The key issue seems to be that you might be trying to simulate multiple threads on a single host thread. Therefore you can't implement blocking system calls that rely on signaling from other threads by spinning/blocking in the syscall code. So this patch forces the system call to bump down the event queue every X cycles so that other simulated threads can make forward progress. - Michael LeBeane On Nov. 7, 2016, 11:20 p.m., Brandon Potter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3680/ > --- > > (Updated Nov. 7, 2016, 11:20 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > --- > > Changeset 11702:149a5af69d1a > --- > syscall_emul: [patch 13/22] add system call retry capability > > This changeset adds functionality that allows system calls to retry without > affecting system state during on system call returns. > > We need this functionality to solve problems with blocking system calls > in multi-process or multi-threaded simulations where information is passed > between processes/threads. > > For example, consider two processes that are producer/consumer. They can > use file descriptors and read/write to pass the information between one > another. However if the consumer calls the blocking read system call before > the producer has produced anything, the call will block the event queue and > deadlock the simulation. The trick it to recognize that the system calls will > block and then reschedule at some later point when the call would succeed > without blocking. In subsequent patches, we recognize that a syscall will' > block by calling a non-blocking poll and check for events. > > > Diffs > - > > src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/syscall_desc.hh PRE-CREATION > src/sim/syscall_desc.cc PRE-CREATION > src/cpu/checker/cpu.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/checker/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/minor/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/commit.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/commit_impl.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/cpu.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/cpu.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/dyn_inst.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/dyn_inst_impl.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/thread_state.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/atomic.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/timing.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple_thread.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/pseudo_inst.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/BaseCPU.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/base.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/base.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/arm/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/mips/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/power/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/sparc/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/sparc/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/isa/decoder/one_byte_opcodes.isa > 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/isa/decoder/two_byte_opcodes.isa > 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/alpha/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/arm/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > > Diff: http://reviews.gem5.org/r/3680/diff/ > > > Testing > --- > > > Thanks, > > Brandon
Re: [gem5-dev] Review Request 3680: syscall_emul: [patch 13/22] add system call retry capability
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3680/#review9056 --- This patch looks ok to me, as it seems we're more-or-less implementing sleep functionality for the blocked process, but I have a couple of questions: 1) Can you expand on your statement that this supports retries without affecting system state? What state are you referring to? Certainly the number of simulated cycles, etc. will be updated as the blocked process waits. 2) Do you have any feeling for how this will affect apps that poll on some of the syscalls? E.g., if the syscall would have returned EAGAIN (or similar) will this no longer be exposed to the calling app? - Tony Gutierrez On Nov. 7, 2016, 3:20 p.m., Brandon Potter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3680/ > --- > > (Updated Nov. 7, 2016, 3:20 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > --- > > Changeset 11702:149a5af69d1a > --- > syscall_emul: [patch 13/22] add system call retry capability > > This changeset adds functionality that allows system calls to retry without > affecting system state during on system call returns. > > We need this functionality to solve problems with blocking system calls > in multi-process or multi-threaded simulations where information is passed > between processes/threads. > > For example, consider two processes that are producer/consumer. They can > use file descriptors and read/write to pass the information between one > another. However if the consumer calls the blocking read system call before > the producer has produced anything, the call will block the event queue and > deadlock the simulation. The trick it to recognize that the system calls will > block and then reschedule at some later point when the call would succeed > without blocking. In subsequent patches, we recognize that a syscall will' > block by calling a non-blocking poll and check for events. > > > Diffs > - > > src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/syscall_desc.hh PRE-CREATION > src/sim/syscall_desc.cc PRE-CREATION > src/cpu/checker/cpu.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/checker/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/minor/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/commit.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/commit_impl.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/cpu.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/cpu.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/dyn_inst.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/dyn_inst_impl.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/thread_state.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/atomic.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/timing.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple_thread.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/pseudo_inst.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/BaseCPU.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/base.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/base.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/arm/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/mips/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/power/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/sparc/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/sparc/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/isa/decoder/one_byte_opcodes.isa > 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/isa/decoder/two_byte_opcodes.isa > 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/alpha/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/arm/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > > Diff:
Re: [gem5-dev] Review Request 3680: syscall_emul: [patch 13/22] add system call retry capability
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3680/ --- (Updated Nov. 7, 2016, 11:20 p.m.) Review request for Default. Repository: gem5 Description (updated) --- Changeset 11702:149a5af69d1a --- syscall_emul: [patch 13/22] add system call retry capability This changeset adds functionality that allows system calls to retry without affecting system state during on system call returns. We need this functionality to solve problems with blocking system calls in multi-process or multi-threaded simulations where information is passed between processes/threads. For example, consider two processes that are producer/consumer. They can use file descriptors and read/write to pass the information between one another. However if the consumer calls the blocking read system call before the producer has produced anything, the call will block the event queue and deadlock the simulation. The trick it to recognize that the system calls will block and then reschedule at some later point when the call would succeed without blocking. In subsequent patches, we recognize that a syscall will' block by calling a non-blocking poll and check for events. Diffs (updated) - src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/sim/syscall_desc.hh PRE-CREATION src/sim/syscall_desc.cc PRE-CREATION src/cpu/checker/cpu.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/checker/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/minor/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/o3/commit.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/o3/commit_impl.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/o3/cpu.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/o3/cpu.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/o3/dyn_inst.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/o3/dyn_inst_impl.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/o3/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/o3/thread_state.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/simple/atomic.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/simple/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/simple/timing.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/simple_thread.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/sim/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/sim/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/x86/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/x86/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/x86/pseudo_inst.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/BaseCPU.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/base.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/cpu/base.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/arm/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/mips/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/power/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/sparc/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/sparc/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/x86/isa/decoder/one_byte_opcodes.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/x86/isa/decoder/two_byte_opcodes.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/alpha/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 src/arch/arm/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 Diff: http://reviews.gem5.org/r/3680/diff/ Testing --- Thanks, Brandon Potter ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
