In PathSearchFunc.__call__(), filename is the name of the file
while filepath contains the relative path to the missing file
relative to $M5_PATH.
Outputing the filepath in the error message makes the error
message more useful as it provides the expected location of
the file as well as the name of the file.
Change-Id: I5f1fdb9e48ac9ae59a26d33331a4a40bc9ff9acd
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45105
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ACPI's MADT describes the interrupt system of a processor/system and
partially replaces the Intel MP tables. The config now simply adds the
ACPI variant, so an OS can use either Intel MP or ACPI for interrupt
configuration.
Change-Id: Ie3d293aac0925666f7661a03eab10218f04c8d0c
Signed-off-by: Maximilian Stein <m@steiny.biz>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42825
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This is an initial configuration capable of booting Linux and
registering a PCI device which registers as an AMD Vega 10 (Frontier
Edition) GPU. It it loosely based on the the example/fs.py and gem5 book
full system example scripts. The top-level file is meant to be modular
such that convenience scripts can be created to set arguments
automatically and then call the main run function.
This will evolve over time as more full-system GPU components are added
and the network topology needed for disjoint address spaces is created
for the VIPER protocol.
Change-Id: I7002213ca8de5eb73919e49fb11840a688744012
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44907
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The prior example config for FS fails SMP boot on the KVMX86CPU.
These updates incorporate logic x86-boot-tests/system/
[system.py|run_exit.py] as well as configs/example/arm/
fs_bigLITTLE.py to enable both single processor and SMP boot.
Each KVM VM now uses its own eventq and a non-zero sim_quantum.
Change-Id: I9c73a2f6f2ca604aecd31f45570423c58f85020f
Signed-off-by: Kevin Loughlin <kevlough@umich.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41602
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Viper is checking for the dma's type before making the port assignment.
In FullSystem mode the IDE device is a PortRef and does not have an
attribute 'type.' This handles the various types a bit better and
ensures that IDE device, the protocol tester, and upcoming DMA devices
related to FullSystem can be added.
Change-Id: I6879b25c6aabbbc22b0ee8dc9cbfec6399f70daa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44806
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
GPUCoalescers in FullSystem mode should not be connected to the piobus
since they reside on a completely different RubyPort. There is also no
concept of IO requests from GPU so any request attempting to use the
default port (pio) should fatal. Further, coalescers do not implement
the connectIOPorts function.
This avoids coalescers by checking is_cpu_sequencer, which I believe is
the purpose of that boolean.
Change-Id: I482dd631292ca20e3bcd856489376f9b38457200
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44805
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
GPU MTYPE is currently set using a global config passed to the
PACoalescer. This patch enables MTYPE to be set by the shader on a
per-request bases. In real hardware, the MTYPE is extracted from a
GPUVM PTE during address translation. However, our current simulator
only models x86 page tables which do not have the appropriate bits for
GPU MTYPES. Rather than hacking non-x86 bits into our x86 page table
models, this patch instead keeps an interval tree of all pages that
request custom MTYPES in the driver itself. This is currently
only used to map host pages to the GPU as uncacheable, but is easily
extensible to other MTYPES.
Change-Id: I7daab0ffae42084b9131a67c85cd0aa4bbbfc8d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42216
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There was a merge error caused by new options being added to this script
while all scripts were being converted from optparse. This fixes the
error.
This also removes the mostly unused setOption / getOption as you can
directly assign a value to an argument after parsing
Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba5f0fbf5b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44785
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The --restore_simpoint_checkpoint option is a boolean;
however if no default value is supplied, optparse sets the
default value to None
This is not valid for argparse. Argparse recognizes the store_true
action and it is automatically treating the option as a boolean,
hence providing a default=False instead of default=None
Change-Id: I6b09edf6911be71a06001730be1232a1b5c8482c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44765
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
New topology ripped from Fiji to support dGPU. A dGPU flag is added to
the config which is propogated to the driver. The emulated driver is
now able to properly deal with dGPU ioctls and mmaps. For now, dGPU
physical memory is allocated from the host, but this is easy to change
once we get a GPU memory controller up and running.
Change-Id: I594418482b12ec8fb2e4018d8d0371d56f4f51c8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42214
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This vestigial device provides a thin layer of indirection between
devices and the CPUs in a system. It's basically a collection of helper
functions, but since it's a SimObject it needs to be instantiated in
python and added to configurations.
Change-Id: I029d2314ae0bb890678e1e68dafcdab4bfe49beb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43347
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is adding an extra parameter to the Ruby.create_system
function. The idea is to remove any assumption about cpu configuration
in the ruby scripts.
At the moment the scripts are assuming a flat list of cpu assigned
to the system object. Unfortunately this is not standardized, as
some systems might empoloy a different layout of cpus, like grouping
them in cluster objects.
With this patch we are allowing client scripts to provide the cpu list
as an extra argument
This has the extra benefit of removing the indexing hack
if len(system.cpu) == 1:
which was present in most scripts
Change-Id: Ibc06b920273cde4f7c394d61c0ca664a7143cd27
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43287
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Changes:
1. RiscvBareMetal
The RiscvBareMetal class and API are preserved for backwards
compatibility, but the base class RiscvFSWorkload is removed
as it inherits from the Workload class. However, most needed
functionalities are already implemented in the KernelWorkload
class
2. RiscvLinux
The RiscvLinux class is added. A dtb filename can be specified
to be loaded to the corresponding memory address.
3. HiFive, Clint, Plic, Uart8250, VirtIOMMIO
Devicetree node generation function is added.
4. tlb, faults
Unnecessary includes of arch/riscv/fs_workload are removed.
Change-Id: Ia239b5614bd93d8e794330ead266f6121a4d13cb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42053
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
The function had been introduced in the past when we needed to
instantiate either an ArmSystem or a LinuxArmSystem depending on the
workload. Now that the workload object has been introduced in gem5, we
always instantiate an ArmSystem in FS mode, hence we don't need a
function to generate the System object
Change-Id: I79ccf31087b84521cce32da71bc835ff202dc432
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43285
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We are adding a controller method to MemInterface objects making
them able to generate the appropriate memory controller.
This will bring the following benefits
a) Semplification: It will simplify MemConfig.config_mem
b) Reusability: Scripts not using config_mem
won't have to duplicate the if...else checks
c) Modularity: Users will be able to define their own
dram interfaces without needing to handle the mem_ctrl
mapping in the shared MemConfig.py module
Change-Id: I4b836fd7c91675cf7aacc644f25989484d5be3ec
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42074
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Wendy Elsasser <wendy.elsasser@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Changed format from yaml to plain python. The new py configuration
file, when provided, must specialize the CHI node types defined in
configs/ruby/CHI_config.py (moved from configs/ruby/CHI.py). This
is required in order to setup the node->router bindings when the
CustomMesh topology is used.
See configs/example/noc_config/2x4.py (replaces
configs/example/noc_config/2x4.yaml) for an example.
--noc-config was also renamed to --chi-config, since the CHI node types
can be fully specialized in the configuration file.
Change-Id: Ic0c5407dba3d2483d5c30634c115b5410a5228fd
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43123
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch add a new Ruby cache coherence protocol based on Arm' AMBA5
CHI specification. The CHI protocol defines and implements two state
machine types:
- Cache_Controller: generic cache controller that can be configured as:
- Top-level L1 I/D cache
- A intermediate level (L2, L3, ...) private or shared cache
- A CHI home node (i.e. the point of coherence of the system and
has the global directory)
- A DMA requester
- Memory_Controller: implements a CHI slave node and interfaces with
gem5 memory controller. This controller has the functionality of a
Directory_Controller on the other Ruby protocols, except it doesn't
have a directory.
The Cache_Controller has multiple cache allocation/deallocation
parameters to control the clusivity with respect to upstream caches.
Allocation can be completely disabled to use Cache_Controller as a
DMA requester or as a home node without a shared LLC.
The standard configuration file configs/ruby/CHI.py provides a
'create_system' compatible with configs/example/fs.py and
configs/example/se.py and creates a system with private L1/L2 caches
per core and a shared LLC at the home nodes. Different cache topologies
can be defined by modifying 'create_system' or by creating custom
scripts using the structures defined in configs/ruby/CHI.py.
This patch also includes the 'CustomMesh' topology script to be used
with CHI. CustomMesh generates a 2D mesh topology with the placement
of components manually defined in a separate configuration file using
the --noc-config parameter.
The example in configs/example/noc_config/2x4.yaml creates a simple 2x4
mesh. For example, to run a SE mode simulation, with 4 cores,
4 mem ctnrls, and 4 home nodes (L3 caches):
build/ARM/gem5.opt configs/example/se.py \
--cmd 'tests/test-progs/hello/bin/arm/linux/hello' \
--ruby --num-cpus=4 --num-dirs=4 --num-l3caches=4 \
--topology=CustomMesh --noc-config=configs/example/noc_config/2x4.yaml
If one doesn't care about the component placement on the interconnect,
the 'Crossbar' and 'Pt2Pt' may be used and they do not require the
--noc-config option.
Additional authors:
Joshua Randall <joshua.randall@arm.com>
Pedro Benedicte <pedro.benedicteillescas@arm.com>
Tuan Ta <tuan.ta2@arm.com>
JIRA: https://gem5.atlassian.net/browse/GEM5-908
Change-Id: I856524b0afd30842194190f5bd69e7e6ded906b0
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42563
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a DMA thread tester to the Ruby GPU tester to test the DMA state
machine in the protocol. Currently creates a dummy DMA device to pass
through Ruby.py and scans for the DMA sequencers due to opaqueness of
Ruby.py.
DMA atomics not yet supported as there is no protocol that implements
atomic transitions in the DMA state machine file.
Example run command:
build/GCN3_X86/gem5.opt configs/example/ruby_gpu_random_test.py \
--test-length=1000
Change-Id: I63d83e00fd0dcbb1e34c6704d1c2d49ed4e77722
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39936
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Event creation and management support from emulated drivers is required
to support interruptible signals in HSA and this support was not
available. This changeset adds the event creation and management support
in the emulated driver. With this patch, each interruptible signal
created by the HSA runtime is associated with a signal event. The HSA
runtime can then put a thread waiting on a signal condition to sleep
asking the driver to monitor the event associated with that signal. If
the signal is modified by the GPU, the dispatcher notifies the driver
about signal value change. If the modifier is a CPU thread, the thread
will have to make HSA API calls to modify the signal and these API calls
will notify the driver about signal value change. Once the driver is
notified about a change in the signal value, the driver checks to see if
any thread is sleeping on that signal and wake up the sleeping thread
associated with that event. The driver has also implemented the time_out
wakeup that can wake up the thread after a certain time period has
expired. This is also true for barrier packets.
Each signal has an event address in a kernel managed and allocated
event page that can be used as a mailbox pointer to notify an event.
However, this feature used by non-CPU agents to communicate with the
driver is not implemented by this changeset because the non-CPU HSA
agents in our model can directly communicate with driver in our
implementation. Having said that, adding that feature should be trivial
because the event address and event pages are correctly setup by this
changeset and just adding the event page's virtual address to our PIO
doorbell interface in the page tables and registering that pio address
to the driver should be sufficient. Managing mailbox pointer for an
event is based on event ID and using this event ID as an index into
event page, this changeset already provides a unique mailbox pointer for
each event.
Change-Id: Ic62794076ddd47526b1f952fdb4c1bad632bdd2e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38335
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The baremetal platform is the platform we use for running
user supplied binaries on baremetal hardware.
(simply put, it runs provided binaries without adding
a gem5 bootloader)
Some layers of this software stack might not have a pci driver.
This might be the case for firmware images like edkII
which needs to use a block device to extract the bootloader
and/or the kernel image. Those can use the memory mapped
(in host domain) virtio block device which is already
part of the VExpress_GEM5 platforms
Change-Id: I9c6ba7e1b4566a3999fd9ba20a2bebe191dc3ef8
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39995
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Replacement policy is one of the key points in CPU performance. For ease
of checking the avliable replacment types for any cpu architects,
"replacment policy list" is added in Options.py and ObjectList.py.
Just like Branch Prediction Policies, adding such list would make it efficient for compare cpu performance
regarding different replacment policies especially for Cache.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-853
Change-Id: I97358617038fdcec79fa7e59baba8926284727b4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39195
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
