From c73048df0d701d094f500daf60843cf61ca1e487 Mon Sep 17 00:00:00 2001 From: "Bobby R. Bruce" Date: Thu, 13 Feb 2020 12:33:43 -0800 Subject: [PATCH 1/6] misc: Updated Doxygen to state version as v19.0.0.0 Change-Id: I6baf60e1f59c0e856c2184fcb0211ed85a62a794 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25363 Reviewed-by: Jason Lowe-Power Maintainer: Jason Lowe-Power Tested-by: kokoro --- src/Doxyfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Doxyfile b/src/Doxyfile index 891720a329..5b18e97172 100644 --- a/src/Doxyfile +++ b/src/Doxyfile @@ -31,7 +31,7 @@ PROJECT_NAME = gem5 # This could be handy for archiving the generated documentation or # if some version control system is used. -PROJECT_NUMBER = +PROJECT_NUMBER = v19.0.0.0 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) # base path where the generated documentation will be put. From 8fb933841ff17d91231342f4b56f11bee6e08b09 Mon Sep 17 00:00:00 2001 From: Giacomo Travaglini Date: Mon, 17 Feb 2020 14:27:46 +0000 Subject: [PATCH 2/6] arch-arm: Fix ArmKVM build BaseInterrupts don't have a checkRaw method. This was breaking gem5 compilation on a Arm machine Change-Id: I8717b1bcf64ed14e8a0f63a9dcaca6041dbea4d3 Signed-off-by: Giacomo Travaglini Reviewed-by: Nikos Nikoleris Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25431 Reviewed-by: Jason Lowe-Power Reviewed-by: Gabe Black Tested-by: kokoro --- src/arch/arm/kvm/arm_cpu.cc | 6 ++++-- src/arch/arm/kvm/base_cpu.cc | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/src/arch/arm/kvm/arm_cpu.cc b/src/arch/arm/kvm/arm_cpu.cc index 80576a25a5..24f7be8b2c 100644 --- a/src/arch/arm/kvm/arm_cpu.cc +++ b/src/arch/arm/kvm/arm_cpu.cc @@ -45,6 +45,7 @@ #include #include +#include "arch/arm/interrupts.hh" #include "arch/registers.hh" #include "cpu/kvm/base.hh" #include "debug/Kvm.hh" @@ -270,8 +271,9 @@ ArmKvmCPU::startup() Tick ArmKvmCPU::kvmRun(Tick ticks) { - bool simFIQ(interrupts[0]->checkRaw(INT_FIQ)); - bool simIRQ(interrupts[0]->checkRaw(INT_IRQ)); + auto interrupt = static_cast(interrupts[0]); + const bool simFIQ(interrupt->checkRaw(INT_FIQ)); + const bool simIRQ(interrupt->checkRaw(INT_IRQ)); if (fiqAsserted != simFIQ) { fiqAsserted = simFIQ; diff --git a/src/arch/arm/kvm/base_cpu.cc b/src/arch/arm/kvm/base_cpu.cc index 765965092d..c99e853a3a 100644 --- a/src/arch/arm/kvm/base_cpu.cc +++ b/src/arch/arm/kvm/base_cpu.cc @@ -41,6 +41,7 @@ #include +#include "arch/arm/interrupts.hh" #include "debug/KvmInt.hh" #include "params/BaseArmKvmCPU.hh" @@ -88,8 +89,9 @@ BaseArmKvmCPU::startup() Tick BaseArmKvmCPU::kvmRun(Tick ticks) { - const bool simFIQ(interrupts[0]->checkRaw(INT_FIQ)); - const bool simIRQ(interrupts[0]->checkRaw(INT_IRQ)); + auto interrupt = static_cast(interrupts[0]); + const bool simFIQ(interrupt->checkRaw(INT_FIQ)); + const bool simIRQ(interrupt->checkRaw(INT_IRQ)); if (!vm.hasKernelIRQChip()) { if (fiqAsserted != simFIQ) { From 068ded195c1656b7b5e2b53efc9722ba0bc0d463 Mon Sep 17 00:00:00 2001 From: Adrian Herrera Date: Fri, 14 Feb 2020 09:18:08 +0000 Subject: [PATCH 3/6] arch-arm: Fix CNTFRQ_EL0 permission bits The register is marked as being writable at EL3 only (mon). However the arm arm states the register is accessible at the highest implemented EL. Which means that if EL1 is the highest EL, EL1 code should be able to modify the register value. Change-Id: If9884fa2232869c043c96eba320e3c69efbab517 Reviewed-by: Richard Cooper Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25428 Reviewed-by: Jason Lowe-Power Maintainer: Bobby R. Bruce Tested-by: kokoro --- src/arch/arm/miscregs.cc | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/arch/arm/miscregs.cc b/src/arch/arm/miscregs.cc index c25c24bb7a..0b883a122c 100644 --- a/src/arch/arm/miscregs.cc +++ b/src/arch/arm/miscregs.cc @@ -3707,8 +3707,9 @@ ISA::initializeMiscRegMetadata() InitReg(MISCREG_HTPIDR) .hyp().monNonSecure(); InitReg(MISCREG_CNTFRQ) - .unverifiable() - .reads(1).mon(); + .reads(1) + .highest(system) + .privSecureWrite(aarch32EL3); InitReg(MISCREG_CNTKCTL) .allPrivileges().exceptUserMode(); InitReg(MISCREG_CNTP_TVAL) @@ -4453,7 +4454,9 @@ ISA::initializeMiscRegMetadata() .allPrivileges().exceptUserMode() .mapsTo(MISCREG_CNTKCTL); InitReg(MISCREG_CNTFRQ_EL0) - .reads(1).mon() + .reads(1) + .highest(system) + .privSecureWrite(aarch32EL3) .mapsTo(MISCREG_CNTFRQ); InitReg(MISCREG_CNTPCT_EL0) .reads(1) From a812d862929bb3b47329a88b97fd756a32cf971d Mon Sep 17 00:00:00 2001 From: Jason Lowe-Power Date: Tue, 18 Feb 2020 10:51:58 -0800 Subject: [PATCH 4/6] sim: Fix pseudo instruction parameter loading With the new ABI API the position argument of the pseudo inst ABI was not updated correctly. The position needs to be incremented (at least) once per argument. Note: `position++` must be outside of the function call because of a GCC complaint: build/X86/sim/pseudo_inst.hh:80:48: error: cannot bind non-const lvalue reference of type 'int&' to an rvalue of type 'PseudoInstABI::Position {aka int}' return TheISA::getArgument(tc, position++, sizeof(uint64_t), false); Issue: https://gem5.atlassian.net/browse/GEM5-351 Change-Id: Idd890a587a565b8ad819f094147a02dc1519e997 Signed-off-by: Jason Lowe-Power Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25543 Reviewed-by: Gabe Black Maintainer: Gabe Black Tested-by: kokoro --- src/sim/pseudo_inst.hh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/sim/pseudo_inst.hh b/src/sim/pseudo_inst.hh index 44227aff17..e2d0c612b1 100644 --- a/src/sim/pseudo_inst.hh +++ b/src/sim/pseudo_inst.hh @@ -77,7 +77,10 @@ struct Argument static uint64_t get(ThreadContext *tc, PseudoInstABI::Position &position) { - return TheISA::getArgument(tc, position, sizeof(uint64_t), false); + uint64_t result = TheISA::getArgument(tc, position, sizeof(uint64_t), + false); + position++; + return result; } }; From a7ad3836960749d0cefb4f2c0d1ab82c704e8b9d Mon Sep 17 00:00:00 2001 From: Giacomo Travaglini Date: Wed, 19 Feb 2020 10:59:19 +0000 Subject: [PATCH 5/6] dev-arm: Fix setupBootloader for VExpress_GEM5_V2 Recent changes in the setupBootloader method didn't take into account that the VExpress_GEM5_Base class does require "loc" to be passed to the bootloader setup method: setupBootLoader(self, cur_sys, loc, boot_loader=None) However VExpress_GEM5_V2_Base was just passing cur_sys and boot_loader so that the bootloader was being passed as loc and boot_loader was passed as None (default parameter): super(VExpress_GEM5_V2_Base, self).setupBootLoader( cur_sys, boot_loader) This patch is fixing this by removing loc from the VExpress_GEM5_Base interface: the bootloader defaults (usinbg loc) are being set in the derived classes (V1 and V2) Change-Id: Ic4d4e4fd8d45a7af9207900287828119c3d7d56c Signed-off-by: Giacomo Travaglini Reviewed-by: Nikos Nikoleris Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25583 Reviewed-by: Bobby R. Bruce Tested-by: kokoro --- src/dev/arm/RealView.py | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/dev/arm/RealView.py b/src/dev/arm/RealView.py index 2de99ca9ae..250a889b63 100644 --- a/src/dev/arm/RealView.py +++ b/src/dev/arm/RealView.py @@ -1080,9 +1080,7 @@ Interrupts: self._attach_device(dev, bus, dma_ports) self.smmu.connect(dev, bus) - def setupBootLoader(self, cur_sys, loc, boot_loader=None): - if boot_loader is None: - boot_loader = [ loc('boot.arm64'), loc('boot.arm') ] + def setupBootLoader(self, cur_sys, boot_loader): super(VExpress_GEM5_Base, self).setupBootLoader( cur_sys, boot_loader, 0x8000000, 0x80000000) @@ -1114,6 +1112,12 @@ class VExpress_GEM5_V1_Base(VExpress_GEM5_Base): Gicv2mFrame(spi_base=256, spi_len=64, addr=0x2c1c0000), ] + def setupBootLoader(self, cur_sys, loc, boot_loader=None): + if boot_loader is None: + boot_loader = [ loc('boot.arm64'), loc('boot.arm') ] + super(VExpress_GEM5_V1_Base, self).setupBootLoader( + cur_sys, boot_loader) + def _on_chip_devices(self): return super(VExpress_GEM5_V1_Base,self)._on_chip_devices() + [ self.gic, self.vgic, self.gicv2m, From 2a2579140d4edb8e5d04578f5892a452950c9600 Mon Sep 17 00:00:00 2001 From: "Bobby R. Bruce" Date: Tue, 18 Feb 2020 11:19:56 -0800 Subject: [PATCH 6/6] misc: Updated CONTRIBUTING.md to reflect altered release policy It has been decided that contributions can be made to the staging branch (assuming they are of a high enough importance). The staging branch will then be merged into both the master and develop branches. The time in which the staging branch exists has been extended to two weeks. Jira: https://gem5.atlassian.net/browse/GEM5-334 Change-Id: I3cd0b344be9768871b7fd79261c603d17d8ac1b8 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25523 Reviewed-by: Bobby R. Bruce Reviewed-by: Daniel Carvalho Maintainer: Bobby R. Bruce Tested-by: kokoro --- CONTRIBUTING.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 08619cb317..72cb250a85 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -490,28 +490,30 @@ follows: 1. Developers will be notified, via the gem5-dev mailing list, that a new release of gem5 will occur. This should be no sooner than 2 weeks prior to the -expected release date. This gives time for developers to ensure their changes -for the next release are submitted to the develop branch. +creation of the staging branch (the first step in releasing a new version of +gem5). This gives time for developers to ensure their changes for the next +release are submitted to the develop branch. 2. When a release is ready, a new staging branch shall be created by a project -maintainer, from develop, with the name "release-staging-{VERSION}". -The gem5-dev mailing list will be notified that, unless justifiable objections -are made, the staging branch will be merged into the master branch within the -next week, thus marking the new release. +maintainer, from develop, with the name "release-staging-{VERSION}". The +gem5-dev mailing list will be notified that the staging branch will be merged +into the master branch after two weeks, thus marking the new release. 3. The staging branch will have the full suite of gem5 tests run on it to ensure all tests pass and the to-be-released code is in a decent state. -4. If reasonable concerns about the state of the staging branch are made by -members of the gem5 community, then time shall be given for project -contributors to rectify these concerns on the develop branch. After these -changes have been incorporated, the develop branch will be re-merged into the -staging branch. The staging branch will be re-evaluated via the tests, and the -gem5 community informed of the changes with additional time given for more -feedback on the new release. +4. If a user submits a changeset to the staging branch, it will be considered +and undergo the standard Gerrit review process. However, only alterations that +cannot wait until the following release will be accepted for submission into +the branch (i.e., submissions to the staging branch for "last minute" +inclusions to the release should be of a high priority, such as a critical bug +fix). The project maintainers will use their discretion in deciding whether a +change may be submitted directly to the staging branch. All other submissions +to gem5 will continue to be made to the develop branch. Patches submitted +into the staging branch do not need to be re-added to the develop branch. 5. Once signed off by members of the PMC the staging branch shall be merged -into the master branch, and the staging branch deleted. +into the master and develop branch. The staging branch will then be deleted. 6. The master branch shall be tagged with the correct version number for that release. gem5 conforms to a "v{YY}.{MAJOR}.{MINOR}.{HOTFIX}" versioning system. E.g., the first major release of 2022 will be "v22.0.0.0", followed by -"v22.1.0.0". All the releases (with the exemption hotfixes) are considered +"v22.1.0.0". All the releases (with the exception of hotfixes) are considered major releases. For the meantime, there are no minor releases though we keep the minor release numbers in case this policy changes in the future. 7. The gem5-dev and gem5-user mailing lists shall be notified of the new gem5