[gem5-dev] Change in public/gem5[master]: riscv: throw IllegalInstFault when decoding invalid instructions
Tuan Ta has submitted this change and it was merged. ( https://gem5-review.googlesource.com/9261 ) Change subject: riscv: throw IllegalInstFault when decoding invalid instructions .. riscv: throw IllegalInstFault when decoding invalid instructions If an instruction is invalid, some assertions may in the decoder may fail the entire simulation. Instead, we want to raise an IllegalInstFault instead of failing immediately in the decoder if the invalid instruction is being speculatively executed. Change-Id: I5cb72ba06f07f173922f86897ddfdf677e8c702f Reviewed-on: https://gem5-review.googlesource.com/9261 Maintainer: Alec RoelkeReviewed-by: Monir Zaman Reviewed-by: Jason Lowe-Power --- M src/arch/riscv/isa/decoder.isa 1 file changed, 58 insertions(+), 19 deletions(-) Approvals: Jason Lowe-Power: Looks good to me, approved Monir Zaman: Looks good to me, but someone else must approve Alec Roelke: Looks good to me, approved diff --git a/src/arch/riscv/isa/decoder.isa b/src/arch/riscv/isa/decoder.isa index bbed650..e3992d7 100644 --- a/src/arch/riscv/isa/decoder.isa +++ b/src/arch/riscv/isa/decoder.isa @@ -117,7 +117,9 @@ if (CIMM1 > 0) imm |= ~((uint64_t)0x1F); }}, {{ -assert(RC1 != 0); +if (RC1 == 0) { +fault = make_shared("source reg x0"); +} Rc1_sd = (int32_t)Rc1_sd + imm; }}); 0x2: c_li({{ @@ -125,7 +127,9 @@ if (CIMM1 > 0) imm |= ~((uint64_t)0x1F); }}, {{ -assert(RC1 != 0); +if (RC1 == 0) { +fault = make_shared("source reg x0"); +} Rc1_sd = imm; }}); 0x3: decode RC1 { @@ -137,7 +141,9 @@ if (CIMM1 > 0) imm |= ~((int64_t)0x1FF); }}, {{ -assert(imm != 0); +if (imm == 0) { +fault = make_shared("immediate = 0"); +} sp_sd = sp_sd + imm; }}); default: c_lui({{ @@ -145,8 +151,12 @@ if (CIMM1 > 0) imm |= ~((uint64_t)0x1); }}, {{ -assert(RC1 != 0 && RC1 != 2); -assert(imm != 0); +if (RC1 == 0 || RC1 == 2) { +fault = make_shared("source reg x0"); +} +if (imm == 0) { +fault = make_shared("immediate = 0"); +} Rc1_sd = imm; }}); } @@ -155,14 +165,18 @@ format CIOp { 0x0: c_srli({{ imm = CIMM5 | (CIMM1 << 5); -assert(imm != 0); }}, {{ +if (imm == 0) { +fault = make_shared("immediate = 0"); +} Rp1 = Rp1 >> imm; }}, uint64_t); 0x1: c_srai({{ imm = CIMM5 | (CIMM1 << 5); -assert(imm != 0); }}, {{ +if (imm == 0) { +fault = make_shared("immediate = 0"); +} Rp1_sd = Rp1_sd >> imm; }}, uint64_t); 0x2: c_andi({{ @@ -230,9 +244,13 @@ 0x2: decode COPCODE { 0x0: CIOp::c_slli({{ imm = CIMM5 | (CIMM1 << 5); -assert(imm != 0); }}, {{ -assert(RC1 != 0); +if (imm == 0) { +fault = make_shared("immediate = 0"); +} +if (RC1 == 0) { +fault = make_shared("source reg x0"); +} Rc1 = Rc1 << imm; }}, uint64_t); format CompressedLoad { @@ -250,7 +268,9 @@ CIMM1 << 5 | CIMM5<1:0> << 6; }}, {{ -assert(RC1 != 0); +if (RC1 == 0) { +fault = make_shared("source reg x0"); +} Rc1_sd = Mem_sw; }}, {{ EA = sp + offset; @@ -260,7 +280,9 @@ CIMM1 << 5 | CIMM5<2:0> << 6; }}, {{ -assert(RC1 != 0); +if (RC1 == 0) { +fault = make_shared("source reg x0"); +} Rc1_sd = Mem_sd; }}, {{ EA = sp + offset; @@ -269,22 +291,31 @@ 0x4: decode CFUNCT1 { 0x0: decode RC2 { 0x0:
Re: [gem5-dev] Multicore ARM v8 KVM based simulation
This is on an chromebook based on the RK3399 with only ~4GB of RAM which is not ideal, although we have a bigger machine in the works for the future. I agree with your reasoning and don't think option 1 is a problem. We're using static DTBs so I don't think that's an issue either. In my script, I'm not doing anything smart with the event queues, so that's likely at least part of the problem. When I tried using fs_bigLITTLE.py I ran into what looked like a similar issue so that might not be the whole story, but it's definitely something I should fix up. I'll let you know how that goes! Gabe On Mon, Mar 19, 2018 at 4:30 AM, Andreas Sandbergwrote: > Hmm, OK, this is very strange. > > What type of hardware are you running on? Is it an A57-based chip or > something else? Also, what's your simulation quantum? I have been able to > run with a 0.5ms quantum (5e8 ticks). > I think the following trace of two CPUs running in KVM should be roughly > equivalent to the trace you shared earlier. It was generated on a > commercially available 8xA57 (16GiB ram) using the following command (gem5 > rev 9dc44b417): > > gem5.opt -r --debug-flags Kvm,KvmIO,KvmRun > configs/example/arm/fs_bigLITTLE.py \ > --sim-quantum '0.5ms' \ > --cpu-type kvm --big-cpus 0 --little-cpus 2 \ > --dtb system/arm/dt/armv8_gem5_v1_2cpu.dtb --kernel > vmlinux.aarch64.4.4-d318f95d0c > > Note that the tick counts are a bit weird since we have three different > event queues at play (1 for devices and one per CPU). > > 0: system.littleCluster.cpus0: KVM: Executing for 5 ticks > 0: system.littleCluster.cpus1: KVM: Executing for 5 ticks > 0: system.littleCluster.cpus0: KVM: Executed 79170 instructions in > 176363 cycles (88181504 ticks, sim cycles: 176363). > 88182000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6) > 88182000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: > 0x1c090024, len: 4) > 88332000: system.littleCluster.cpus0: Entering KVM... > 88332000: system.littleCluster.cpus0: KVM: Executing for 411668000 ticks > 88332000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in > 16854 cycles (8427000 ticks, sim cycles: 16854). > 96759000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6) > 96759000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: > 0x1c090030, len: 4) > 0: system.littleCluster.cpus1: KVM: Executed 409368 instructions in > 666400 cycles (33320 ticks, sim cycles: 666400). > 33320: system.littleCluster.cpus1: Entering KVM... > 33320: system.littleCluster.cpus1: KVM: Executing for 16680 ticks > 96909000: system.littleCluster.cpus0: Entering KVM... > 96909000: system.littleCluster.cpus0: KVM: Executing for 403091000 ticks > 96909000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in > 15257 cycles (7628500 ticks, sim cycles: 15257). > 104538000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6) > 104538000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: > 0x1c0100a0, len: 4) > 33320: system.littleCluster.cpus1: KVM: Executed 47544 instructions in > 200820 cycles (10041 ticks, sim cycles: 200820). > 43361: system.littleCluster.cpus1: Entering KVM... > 43361: system.littleCluster.cpus1: KVM: Executing for 6639 ticks > 104688000: system.littleCluster.cpus0: Entering KVM... > 104688000: system.littleCluster.cpus0: KVM: Executing for 395312000 ticks > 104688000: system.littleCluster.cpus0: KVM: Executed 4382 instructions in > 14942 cycles (7471000 ticks, sim cycles: 14942). > > Comparing this trace to yours, I'd say that there the frequent KVM exits > look a bit suspicious. I would expect secondary CPUs to make very little > process while the main CPU initializes the system and starts the early boot > code. > > There area couple of possibilities that might be causing issues: > > 1) There is some CPU ID weirdness that confuses the boot code and puts > both CPUs in the holding pen. This seems unlikely since there are some > writes to the UART. > > 2) Some device is incorrectly mapped to the CPU event queues and causes > frequent KVM exits. Have a look at _build_kvm in fs_bigLITTLE.py, it > doesn't use configs/common, so no need to tear your eyes out. ;) Do you map > event queues in the same way? It's mapping all simulated devices to one > event queue and the CPUs to private event queues. It's important to remap > CPU child devices to the device queue instead of the CPU queue. Failing to > do this will cause chaos, madness, and quite possibly result in Armageddon. > > 3) You're using DTB autogeneration. This doesn't work for KVM guests due > to issues with the timer interrupt specification. We have a patch for the > timer that we are testing internally. Sorry. :( > > Regards, > Andreas > On 16/03/2018 23:20, Gabe Black wrote: > > Ok, diving into this a little deeper, it looks like execution is > progressing but is making
[gem5-dev] Change in public/gem5[master]: arch-riscv: implement bare metal specific system class
Robert Scheffel has uploaded this change for review. ( https://gem5-review.googlesource.com/9281 Change subject: arch-riscv: implement bare metal specific system class .. arch-riscv: implement bare metal specific system class A new system class was implemented, that manages variables, which are only relevant for bare metal applications. That will help to enable both, bare metal systems and later on linux systems. Change-Id: I379315bbea5042ae9f933ab24222a59b619b95a4 --- M src/arch/riscv/RiscvSystem.py M src/arch/riscv/SConscript A src/arch/riscv/bare_metal/system.cc A src/arch/riscv/bare_metal/system.hh M src/arch/riscv/system.cc M src/arch/riscv/system.hh 6 files changed, 151 insertions(+), 49 deletions(-) diff --git a/src/arch/riscv/RiscvSystem.py b/src/arch/riscv/RiscvSystem.py index df0f964..89e6cf0 100644 --- a/src/arch/riscv/RiscvSystem.py +++ b/src/arch/riscv/RiscvSystem.py @@ -32,8 +32,15 @@ from m5.params import * from System import System + class RiscvSystem(System): type = 'RiscvSystem' cxx_header = 'arch/riscv/system.hh' -bootloader = Param.String("File, that contains the bootloader code") +resetVect = Param.Addr(0x0, 'Reset vector') load_addr_mask = 0x + + +class BareMetalRiscvSystem(RiscvSystem): +type = 'BareMetalRiscvSystem' +cxx_header = 'arch/riscv/bare_metal/system.hh' +bootloader = Param.String("File, that contains the bootloader code") diff --git a/src/arch/riscv/SConscript b/src/arch/riscv/SConscript index 2482414..2ddba72 100644 --- a/src/arch/riscv/SConscript +++ b/src/arch/riscv/SConscript @@ -62,6 +62,8 @@ Source('linux/process.cc') Source('linux/linux.cc') +Source('bare_metal/system.cc') + SimObject('RiscvInterrupts.py') SimObject('RiscvISA.py') SimObject('RiscvTLB.py') diff --git a/src/arch/riscv/bare_metal/system.cc b/src/arch/riscv/bare_metal/system.cc new file mode 100644 index 000..c8b3ad2 --- /dev/null +++ b/src/arch/riscv/bare_metal/system.cc @@ -0,0 +1,80 @@ +/* + * Copyright (c) 2018 TU Dresden + * All rights reserved + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are + * met: redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer; + * redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution; + * neither the name of the copyright holders nor the names of its + * contributors may be used to endorse or promote products derived from + * this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * Authors: Robert Scheffel + */ + +#include "arch/riscv/bare_metal/system.hh" + +#include "base/loader/object_file.hh" + +BareMetalRiscvSystem::BareMetalRiscvSystem(Params *p) +: RiscvSystem(p) +{ +bootloaderSymtab = new SymbolTable; + +// load bootloader code into memory +bootloader = createObjectFile(p->bootloader); +if (bootloader == NULL) { + fatal("Could not load bootloader file %s", p->bootloader); +} + +// load symbols +if (!bootloader->loadGlobalSymbols(bootloaderSymtab)) { +panic("Could not load bootloader symbols\n"); +} + +if (!bootloader->loadLocalSymbols(bootloaderSymtab)) { +panic("Could not load bootloader symbols\n"); +} + +_resetVect = bootloader->entryPoint(); +} + +BareMetalRiscvSystem::~BareMetalRiscvSystem() +{ +delete bootloaderSymtab; +delete bootloader; +} + +void +BareMetalRiscvSystem::initState() +{ +// Call the initialisation of the super class +RiscvSystem::initState(); + +// load program sections into memory +if (!bootloader->loadSections(physProxy)) { +warn("could not load sections to memory"); +} +} + +BareMetalRiscvSystem * +BareMetalRiscvSystemParams::create() +{ +return new BareMetalRiscvSystem(this); +} diff --git a/src/arch/riscv/bare_metal/system.hh
[gem5-dev] Change in public/gem5[master]: arch-riscv: enable rudimentary fs simulation
Robert Scheffel has uploaded this change for review. ( https://gem5-review.googlesource.com/9282 Change subject: arch-riscv: enable rudimentary fs simulation .. arch-riscv: enable rudimentary fs simulation The RiscvSystem class is extended with a variable, that indicates, if we execute a bare metal system or not. Change-Id: I973793fe723ce0b2d58d3f3cfd920d3c7106fc63 --- M src/arch/riscv/RiscvSystem.py M src/arch/riscv/system.cc M src/arch/riscv/system.hh M src/arch/riscv/tlb.cc 4 files changed, 82 insertions(+), 37 deletions(-) diff --git a/src/arch/riscv/RiscvSystem.py b/src/arch/riscv/RiscvSystem.py index 89e6cf0..a9eca6e 100644 --- a/src/arch/riscv/RiscvSystem.py +++ b/src/arch/riscv/RiscvSystem.py @@ -28,6 +28,7 @@ # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # # Authors: Alec Roelke +# Robert Scheffel from m5.params import * from System import System @@ -36,6 +37,7 @@ class RiscvSystem(System): type = 'RiscvSystem' cxx_header = 'arch/riscv/system.hh' +bare_metal = Param.Bool(False, "Using Bare Metal Application?") resetVect = Param.Addr(0x0, 'Reset vector') load_addr_mask = 0x @@ -44,3 +46,5 @@ type = 'BareMetalRiscvSystem' cxx_header = 'arch/riscv/bare_metal/system.hh' bootloader = Param.String("File, that contains the bootloader code") + +bare_metal = True diff --git a/src/arch/riscv/system.cc b/src/arch/riscv/system.cc index c36aa99..2b33923 100644 --- a/src/arch/riscv/system.cc +++ b/src/arch/riscv/system.cc @@ -29,6 +29,7 @@ * Authors: Ali Saidi * Nathan Binkert * Jaidev Patwardhan + * Robert Scheffel */ #include "arch/riscv/system.hh" @@ -46,6 +47,7 @@ RiscvSystem::RiscvSystem(Params *p) : System(p), + _isBareMetal(p->bare_metal), _resetVect(p->resetVect) { } @@ -63,6 +65,15 @@ return dynamic_cast(tc->getSystemPtr())->resetVect(); } +/** + * Return the bare metal checker. + */ +bool +RiscvSystem::isBareMetal(ThreadContext* tc) +{ +return dynamic_cast(tc->getSystemPtr())->isBareMetal(); +} + Addr RiscvSystem::fixFuncEventAddr(Addr addr) { @@ -84,4 +95,3 @@ { return new RiscvSystem(this); } - diff --git a/src/arch/riscv/system.hh b/src/arch/riscv/system.hh index 4971a10..46276b3 100644 --- a/src/arch/riscv/system.hh +++ b/src/arch/riscv/system.hh @@ -29,6 +29,7 @@ * Authors: Ali Saidi * Nathan Binkert * Jaidev Patwardhan + * Robert Scheffel */ #ifndef __ARCH_RISCV_SYSTEM_HH__ @@ -48,6 +49,8 @@ class RiscvSystem : public System { protected: +// checker for bare metal application +bool _isBareMetal; // entry point for simulation Addr _resetVect; @@ -56,12 +59,18 @@ RiscvSystem(Params *p); ~RiscvSystem(); -// return reset address +// return reset vector Addr resetVect() const { return _resetVect; } +// return bare metal checker +bool isBareMetal() const { return _isBareMetal; } + // return reset address of thread context static Addr resetVect(ThreadContext* tc); +// return bare metal checker of thread context +static bool isBareMetal(ThreadContext* tc); + virtual bool breakpoint(); public: @@ -101,4 +110,3 @@ }; #endif - diff --git a/src/arch/riscv/tlb.cc b/src/arch/riscv/tlb.cc index b92327f..96b8bdb 100644 --- a/src/arch/riscv/tlb.cc +++ b/src/arch/riscv/tlb.cc @@ -1,7 +1,6 @@ /* * Copyright (c) 2001-2005 The Regents of The University of Michigan * Copyright (c) 2007 MIPS Technologies, Inc. - * Copyright (c) 2018 TU Dresden * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -32,7 +31,6 @@ * Jaidev Patwardhan * Zhengxing Li * Deyuan Guo - * Robert Scheffel */ #include "arch/riscv/tlb.hh" @@ -43,6 +41,7 @@ #include "arch/riscv/faults.hh" #include "arch/riscv/pagetable.hh" #include "arch/riscv/pra_constants.hh" +#include "arch/riscv/system.hh" #include "arch/riscv/utility.hh" #include "base/inifile.hh" #include "base/str.hh" @@ -289,23 +288,25 @@ { if (FullSystem) { /** - * as we currently support bare metal only, we set the physical flag - * that means we treat all addresses as physical addresses - * no translation needed + * check if we simulate a bare metal system + * if so, we have no tlb, phys addr == virt addr */ -req->setFlags(Request::PHYSICAL); -} +if (RiscvSystem::isBareMetal(tc)) +req->setFlags(Request::PHYSICAL); -if (req->getFlags() & Request::PHYSICAL) { -/** - * we simply set the virtual address to physical address - */ -req->setPaddr(req->getVaddr()); -/** - * check if the request is cacheable - * seems like this could have an impact on
[gem5-dev] Change in public/gem5[master]: arch, arm: Fix implicit-fallthrough GCC warnings
Giacomo Travaglini has uploaded a new patch set (#8) to the change originally created by Chun-Chen TK Hsu. ( https://gem5-review.googlesource.com/9101 ) Change subject: arch, arm: Fix implicit-fallthrough GCC warnings .. arch, arm: Fix implicit-fallthrough GCC warnings GCC 7 generates spurious fallthrough warnings in nested switch blocks where the inner switch block return. There is already a GCC fix [1] submitted for review but, until it is merged into GCC trunk, GEM5 will not build with GCC 7 due to these fallthrough warnings. This patch silences the spurious fallthrough warnings by appending a M5_UNREACHABLE statement in the outer switch cases. Note there is another GEM5 patch [2] to fix other fallthrough warnings. [1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01105.html [2] https://gem5-review.googlesource.com/c/public/gem5/+/8541 Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242 Signed-off-by: Chun-Chen Hsu--- M src/arch/arm/isa/formats/aarch64.isa M src/arch/isa_parser.py 2 files changed, 6 insertions(+), 1 deletion(-) -- To view, visit https://gem5-review.googlesource.com/9101 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I97cd8bfa90a88e93cee60cf27a8c93611d11a242 Gerrit-Change-Number: 9101 Gerrit-PatchSet: 8 Gerrit-Owner: Chun-Chen TK Hsu Gerrit-Assignee: Giacomo Travaglini Gerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Chun-Chen TK Hsu Gerrit-Reviewer: Gabe Black Gerrit-Reviewer: Giacomo Travaglini Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Nikos Nikoleris Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in public/gem5[master]: mem-cache: Create BRRIP Replacement Policy
Hello Jason Lowe-Power, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/8981 to look at the new patch set (#4). Change subject: mem-cache: Create BRRIP Replacement Policy .. mem-cache: Create BRRIP Replacement Policy Implementation of a Bimodal RRIP replacement policy. Change-Id: Iba716eb5df2bf2be156e765f889d94f6ad00c91b --- M src/mem/cache/replacement_policies/ReplacementPolicies.py M src/mem/cache/replacement_policies/SConscript A src/mem/cache/replacement_policies/brrip_rp.cc A src/mem/cache/replacement_policies/brrip_rp.hh 4 files changed, 145 insertions(+), 0 deletions(-) -- To view, visit https://gem5-review.googlesource.com/8981 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: Iba716eb5df2bf2be156e765f889d94f6ad00c91b Gerrit-Change-Number: 8981 Gerrit-PatchSet: 4 Gerrit-Owner: Daniel CarvalhoGerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in public/gem5[master]: mem-cache: Create NRU Replacement Policy
Daniel Carvalho has uploaded a new patch set (#2). ( https://gem5-review.googlesource.com/9001 ) Change subject: mem-cache: Create NRU Replacement Policy .. mem-cache: Create NRU Replacement Policy Implementation of a Not Recently Used replacement policy. Change-Id: I24ab3a6f1db6dcb756b869cfebb5c4bc544170e8 --- M src/mem/cache/replacement_policies/ReplacementPolicies.py M src/mem/cache/replacement_policies/SConscript A src/mem/cache/replacement_policies/nru_rp.cc A src/mem/cache/replacement_policies/nru_rp.hh 4 files changed, 115 insertions(+), 0 deletions(-) -- To view, visit https://gem5-review.googlesource.com/9001 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I24ab3a6f1db6dcb756b869cfebb5c4bc544170e8 Gerrit-Change-Number: 9001 Gerrit-PatchSet: 2 Gerrit-Owner: Daniel CarvalhoGerrit-Reviewer: Daniel Carvalho Gerrit-CC: Jason Lowe-Power Gerrit-CC: Nikos Nikoleris Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in public/gem5[master]: mem-cache: Create RRIP replacement policy
Hello Jason Lowe-Power, Nikos Nikoleris, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/8891 to look at the new patch set (#3). Change subject: mem-cache: Create RRIP replacement policy .. mem-cache: Create RRIP replacement policy Implementation of a Re-Reference Interval Prediction replacement policy. Change-Id: I25d4a59a60ef7ac496c66852e394fd6cbaf50912 --- M src/mem/cache/blk.hh M src/mem/cache/replacement_policies/ReplacementPolicies.py M src/mem/cache/replacement_policies/SConscript A src/mem/cache/replacement_policies/rrip_rp.cc A src/mem/cache/replacement_policies/rrip_rp.hh 5 files changed, 239 insertions(+), 0 deletions(-) -- To view, visit https://gem5-review.googlesource.com/8891 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I25d4a59a60ef7ac496c66852e394fd6cbaf50912 Gerrit-Change-Number: 8891 Gerrit-PatchSet: 3 Gerrit-Owner: Daniel CarvalhoGerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Nikos Nikoleris Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in public/gem5[master]: mem-cache: Create MRU replacement policy
Hello Jason Lowe-Power, Nikos Nikoleris, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/8889 to look at the new patch set (#3). Change subject: mem-cache: Create MRU replacement policy .. mem-cache: Create MRU replacement policy Implementation of a Most Recently Used replacement policy. Change-Id: Id52cb247ca25d4523dcc53490d113695dac6a3f1 --- M src/mem/cache/replacement_policies/ReplacementPolicies.py M src/mem/cache/replacement_policies/SConscript A src/mem/cache/replacement_policies/mru_rp.cc A src/mem/cache/replacement_policies/mru_rp.hh 4 files changed, 176 insertions(+), 0 deletions(-) -- To view, visit https://gem5-review.googlesource.com/8889 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: Id52cb247ca25d4523dcc53490d113695dac6a3f1 Gerrit-Change-Number: 8889 Gerrit-PatchSet: 3 Gerrit-Owner: Daniel CarvalhoGerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Nikos Nikoleris Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in public/gem5[master]: mem-cache: Create BIP Replacement Policy
Hello Jason Lowe-Power, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/9003 to look at the new patch set (#2). Change subject: mem-cache: Create BIP Replacement Policy .. mem-cache: Create BIP Replacement Policy Implementation of a Bimodal Insertion Policy replacement policy. Change-Id: Ife058d0d4310dbcb35858348006189f0b2bf7c37 --- M src/mem/cache/replacement_policies/ReplacementPolicies.py M src/mem/cache/replacement_policies/SConscript A src/mem/cache/replacement_policies/bip_rp.cc A src/mem/cache/replacement_policies/bip_rp.hh 4 files changed, 150 insertions(+), 0 deletions(-) -- To view, visit https://gem5-review.googlesource.com/9003 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: Ife058d0d4310dbcb35858348006189f0b2bf7c37 Gerrit-Change-Number: 9003 Gerrit-PatchSet: 2 Gerrit-Owner: Daniel CarvalhoGerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in public/gem5[master]: mem-cache: Create FIFO replacement policy
Hello Jason Lowe-Power, Nikos Nikoleris, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/ to look at the new patch set (#4). Change subject: mem-cache: Create FIFO replacement policy .. mem-cache: Create FIFO replacement policy Implementation of a First-In, First-Out replacement policy. Change-Id: Id234ec9d29c092dd4516e609da14b8a75a96b5e4 --- M src/mem/cache/replacement_policies/ReplacementPolicies.py M src/mem/cache/replacement_policies/SConscript A src/mem/cache/replacement_policies/fifo_rp.cc A src/mem/cache/replacement_policies/fifo_rp.hh 4 files changed, 144 insertions(+), 0 deletions(-) -- To view, visit https://gem5-review.googlesource.com/ To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: Id234ec9d29c092dd4516e609da14b8a75a96b5e4 Gerrit-Change-Number: Gerrit-PatchSet: 4 Gerrit-Owner: Daniel CarvalhoGerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Nikos Nikoleris Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Change in public/gem5[master]: mem-cache: Create LFU replacement policy
Hello Jason Lowe-Power, Nikos Nikoleris, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/8890 to look at the new patch set (#3). Change subject: mem-cache: Create LFU replacement policy .. mem-cache: Create LFU replacement policy Implementation of a Least Frequently Used replacement policy. Change-Id: I772afccd3a7955777e53d59341e922718db44e5c --- M src/mem/cache/replacement_policies/ReplacementPolicies.py M src/mem/cache/replacement_policies/SConscript A src/mem/cache/replacement_policies/lfu_rp.cc A src/mem/cache/replacement_policies/lfu_rp.hh 4 files changed, 145 insertions(+), 0 deletions(-) -- To view, visit https://gem5-review.googlesource.com/8890 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I772afccd3a7955777e53d59341e922718db44e5c Gerrit-Change-Number: 8890 Gerrit-PatchSet: 3 Gerrit-Owner: Daniel CarvalhoGerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Jason Lowe-Power Gerrit-Reviewer: Nikos Nikoleris Gerrit-MessageType: newpatchset ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Multicore ARM v8 KVM based simulation
Hmm, OK, this is very strange. What type of hardware are you running on? Is it an A57-based chip or something else? Also, what's your simulation quantum? I have been able to run with a 0.5ms quantum (5e8 ticks). I think the following trace of two CPUs running in KVM should be roughly equivalent to the trace you shared earlier. It was generated on a commercially available 8xA57 (16GiB ram) using the following command (gem5 rev 9dc44b417): gem5.opt -r --debug-flags Kvm,KvmIO,KvmRun configs/example/arm/fs_bigLITTLE.py \ --sim-quantum '0.5ms' \ --cpu-type kvm --big-cpus 0 --little-cpus 2 \ --dtb system/arm/dt/armv8_gem5_v1_2cpu.dtb --kernel vmlinux.aarch64.4.4-d318f95d0c Note that the tick counts are a bit weird since we have three different event queues at play (1 for devices and one per CPU). 0: system.littleCluster.cpus0: KVM: Executing for 5 ticks 0: system.littleCluster.cpus1: KVM: Executing for 5 ticks 0: system.littleCluster.cpus0: KVM: Executed 79170 instructions in 176363 cycles (88181504 ticks, sim cycles: 176363). 88182000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6) 88182000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 0x1c090024, len: 4) 88332000: system.littleCluster.cpus0: Entering KVM... 88332000: system.littleCluster.cpus0: KVM: Executing for 411668000 ticks 88332000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 16854 cycles (8427000 ticks, sim cycles: 16854). 96759000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6) 96759000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 0x1c090030, len: 4) 0: system.littleCluster.cpus1: KVM: Executed 409368 instructions in 666400 cycles (33320 ticks, sim cycles: 666400). 33320: system.littleCluster.cpus1: Entering KVM... 33320: system.littleCluster.cpus1: KVM: Executing for 16680 ticks 96909000: system.littleCluster.cpus0: Entering KVM... 96909000: system.littleCluster.cpus0: KVM: Executing for 403091000 ticks 96909000: system.littleCluster.cpus0: KVM: Executed 4384 instructions in 15257 cycles (7628500 ticks, sim cycles: 15257). 104538000: system.littleCluster.cpus0: handleKvmExit (exit_reason: 6) 104538000: system.littleCluster.cpus0: KVM: Handling MMIO (w: 1, addr: 0x1c0100a0, len: 4) 33320: system.littleCluster.cpus1: KVM: Executed 47544 instructions in 200820 cycles (10041 ticks, sim cycles: 200820). 43361: system.littleCluster.cpus1: Entering KVM... 43361: system.littleCluster.cpus1: KVM: Executing for 6639 ticks 104688000: system.littleCluster.cpus0: Entering KVM... 104688000: system.littleCluster.cpus0: KVM: Executing for 395312000 ticks 104688000: system.littleCluster.cpus0: KVM: Executed 4382 instructions in 14942 cycles (7471000 ticks, sim cycles: 14942). Comparing this trace to yours, I'd say that there the frequent KVM exits look a bit suspicious. I would expect secondary CPUs to make very little process while the main CPU initializes the system and starts the early boot code. There area couple of possibilities that might be causing issues: 1) There is some CPU ID weirdness that confuses the boot code and puts both CPUs in the holding pen. This seems unlikely since there are some writes to the UART. 2) Some device is incorrectly mapped to the CPU event queues and causes frequent KVM exits. Have a look at _build_kvm in fs_bigLITTLE.py, it doesn't use configs/common, so no need to tear your eyes out. ;) Do you map event queues in the same way? It's mapping all simulated devices to one event queue and the CPUs to private event queues. It's important to remap CPU child devices to the device queue instead of the CPU queue. Failing to do this will cause chaos, madness, and quite possibly result in Armageddon. 3) You're using DTB autogeneration. This doesn't work for KVM guests due to issues with the timer interrupt specification. We have a patch for the timer that we are testing internally. Sorry. :( Regards, Andreas On 16/03/2018 23:20, Gabe Black wrote: Ok, diving into this a little deeper, it looks like execution is progressing but is making very slow progress for some reason. I added a call to "dump()" before each ioctl invocation which enters the VM and looked at the PC to get an idea of what it was up to. I made sure to put that before the timers to avoid taking up VM time with printing debug stuff. In any case, I see that neither CPU gets off of PC 0 for about 2ms simulated time (~500Hz), and that's EXTREMELY slow for a CPU which is supposed to be running in the ballpark of 2GHz. It's not clear to me why it's making such slow progress, but that would explain why I'm getting very little out on the simulated console. It's just taking forever to make it that far. Any idea why it's going so slow, or how to debug further? Gabe On Wed, Mar 14, 2018 at 7:42 PM, Gabe Black> wrote: Some output
[gem5-dev] Change in public/gem5[master]: mem-cache: Split array indexing and replacement policies.
Hello Nikos Nikoleris, Andreas Sandberg, I'd like you to reexamine a change. Please visit https://gem5-review.googlesource.com/8501 to look at the new patch set (#12). Change subject: mem-cache: Split array indexing and replacement policies. .. mem-cache: Split array indexing and replacement policies. Replacement policies (LRU, Random) are currently considered as array indexing methods, but have completely different functionalities: - Array indexers determine the possible locations for block allocation. This information is used to generate replacement candidates when conflicts happen. - Replacement policies determine which of the replacement candidates should be evicted to make room for new allocations. For this reason, they were split into different classes. Advantages: - Easier and more straightforward to implement other replacement policies (RRIP, LFU, ARC, ...) - Allow easier future implementation of cache organization schemes As now we can't assure the use of sets, the previous way to create a true LRU is not viable. Now a timestamp_bits parameter controls how many bits are dedicated for the timestamp, and a true LRU can be achieved through an infinite number of bits (although a few bits suffice in practice). Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda --- M configs/common/cores/arm/O3_ARM_v7a.py M configs/common/cores/arm/ex5_LITTLE.py M configs/common/cores/arm/ex5_big.py M src/mem/cache/Cache.py M src/mem/cache/base.cc M src/mem/cache/blk.hh M src/mem/cache/cache.cc A src/mem/cache/replacement_policies/ReplacementPolicies.py A src/mem/cache/replacement_policies/SConscript A src/mem/cache/replacement_policies/base.cc A src/mem/cache/replacement_policies/base.hh A src/mem/cache/replacement_policies/lru_rp.cc A src/mem/cache/replacement_policies/lru_rp.hh A src/mem/cache/replacement_policies/random_rp.cc A src/mem/cache/replacement_policies/random_rp.hh M src/mem/cache/tags/SConscript M src/mem/cache/tags/Tags.py M src/mem/cache/tags/base.cc M src/mem/cache/tags/base.hh M src/mem/cache/tags/base_set_assoc.cc M src/mem/cache/tags/base_set_assoc.hh M src/mem/cache/tags/fa_lru.cc M src/mem/cache/tags/fa_lru.hh D src/mem/cache/tags/lru.cc D src/mem/cache/tags/lru.hh D src/mem/cache/tags/random_repl.cc D src/mem/cache/tags/random_repl.hh 27 files changed, 654 insertions(+), 444 deletions(-) -- To view, visit https://gem5-review.googlesource.com/8501 To unsubscribe, or for help writing mail filters, visit https://gem5-review.googlesource.com/settings Gerrit-Project: public/gem5 Gerrit-Branch: master Gerrit-Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda Gerrit-Change-Number: 8501 Gerrit-PatchSet: 12 Gerrit-Owner: Daniel CarvalhoGerrit-Reviewer: Andreas Sandberg Gerrit-Reviewer: Daniel Carvalho Gerrit-Reviewer: Nikos Nikoleris Gerrit-CC: Jason Lowe-Power Gerrit-MessageType: newpatchset ___ 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
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/minor-timing: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-atomic: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/o3-timing: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing: FAILED! *** diff[config.json]: SKIPPED* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing-ruby: FAILED! * build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/o3-timing: FAILED! *** diff[simout]: SKIPPED* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/o3-timing: FAILED! * build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO: FAILED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: CHANGED! * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: CHANGED! --- quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level ---* build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple: CHANGED! * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: passed.* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: CHANGED!*** gem5: OK * build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: CHANGED! *** diff[config.ini]: SKIPPED* build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: CHANGED! * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual: CHANGED! * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: CHANGED!--- quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple --- * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: CHANGED! *** diff[config.ini]: SKIPPED* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: CHANGED! * build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple: CHANGED! * build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level: CHANGED! * build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer: CHANGED! * build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level: CHANGED! * build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory: CHANGED! * build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token: CHANGED! * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: CHANGED! * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: CHANGED! * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: CHANGED! * build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple: CHANGED!* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: passed. * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp: CHANGED! * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp: CHANGED! * build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level: CHANGED! * build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: CHANGED! * build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp: CHANGED! * build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: CHANGED! * build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: CHANGED! * build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: CHANGED! * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: CHANGED! * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: CHANGED! * build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: CHANGED! *** diff[simerr]: SKIPPED* build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple: CHANGED! * build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level: CHANGED! * build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: CHANGED! * build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-timing: CHANGED!*** diff[smred.sv2]: SKIPPED * build/X86/tests/opt/quick/se/70.twolf/x86/linux/simple-atomic: CHANGED! * build/ARM/tests/opt/quick/se/00.hello/arm/linux/simple-timing: CHANGED! * build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing: CHANGED! *