Systemd, which is used by many main stream Linux distributions,
will lead to slow boot if entropy is low. On X86 platforms,
this problem can be alleviated by enabling RDRAND instructions.
However, RISC-V doesn't have similar instructions. For QEMU/KVM,
this problem can be solved by passing randomness from the host
via virtio_rng. But gem5 doesn't have VirtIORng support now.
Some user report that the boot time of riscv-ubuntu-run.py is
too long. To alleviate this problem, this patch add VirtIORng
device support for gem5.
Change-Id: Id93b5703161701212fd6683837034cb0cff590c5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55483
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Setting the physical_vnets_channels parameter enables the emulation of
the bandwidth impact of having multiple physical channels for each
virtual network. This is implemented by computing bandwidth in a
per-vnet/channel basis within Throttle objects. The size of the
message buffers are also scaled according to this setting (when buffer
are not unlimited).
The physical_vnets_bandwidth can be used to override the channel width
set for each link and assign different widths for each virtual network.
The --simple-physical-channels option can be used with the generic
configuration scripts to automatically assign a single physical channel
to each virtual network defined in the protocol.
JIRA: https://gem5.atlassian.net/browse/GEM5-920
Change-Id: Ia8c9ec8651405eac8710d3f4d67f637a8054a76b
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41854
Reviewed-by: Meatboy 106 <garbage2collector@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The BaseCPU type had been specializing itself based on the value of
TARGET_ISA, which is not compatible with building more than one ISA at a
time.
This change refactors the CPU models so that the BaseCPU is more
general, and the ISA specific components are added to the CPU when the
CPU types are fully specialized. For instance, The AtomicSimpleCPU has a
version called X86AtomicSimpleCPU which installs the X86 specific
aspects of the CPU.
This specialization is done in three ways.
1. The mmu parameter is assigned an instance of the architecture
specific MMU type. This provides a reasonable default, but also avoids
having having to use the ISA specific type when the parameter is
created.
2. The ISA specific types are made available as class attributes, and
the utility functions (including __init__!) in the BaseCPU class can
refer to them to get the types they need to set up the CPU at run time.
Because SimObjects have strange, unhelpful semantics as far as assigning
to their attributes, these types need to be set up in a non-SimObject
class, which is then brought in as a base of the actual SimObject type.
Because the metaclass of this other type is just "type", things work
like you would expect. The SimObject doesn't do any special processing
of base classes if they aren't also SimObjects, so these attributes
survive and are accessible using normal lookup in the BaseCPU class.
3. There are some methods like addCheckerCPU and properties like
needsTSO which have ISA specific values or behaviors. These are set in
the ISA specific subclass, where they are inherently specific to an ISA
and don't need to check TARGET_ISA.
Also, the DummyChecker which was set up for the BaseSimpleCPU which
doesn't actually do anything in either C++ or python was not carried
forward. The CPU type still exists, but it isn't installed in the
simple CPUs.
To provide backward compatibility, each ISA implements a .py file which
matches the original .py for a CPU, and the original is renamed with a
Base prefix. The ISA specific version creates an alias with the old CPU
name which maps to the ISA specific type. This way, old scripts which
refer to, for example, AtomicSimpleCPU, will get the X86AtomicSimpleCPU
if the x86 version was compiled in, the ArmAtomicSimpleCPU on arm, etc.
Unfortunately, because of how tags on PySource and by extension SimObjects
are implemented right now, if you set the tags on two SimObjects or
PySources which have the same module path, the later will overwrite the
former whether or not they both would be included. There are some
changes in review which would revamp this and make it work like you
would expect, without this central bookkeeping which has the conflict.
Since I can't use that here, I fell back to checking TARGET_ISA to
decide whether to tell SCons about those files at all.
In the long term, this mechanism should be revamped so that these
compatibility types are only available if there is exactly one ISA
compiled into gem5. After the configs have been updated and no longer
assume they can use AtomicSimpleCPU in all cases, then these types can
be deleted.
Also, because ISAs can now either provide subclasses for a CPU or not,
the CPU_MODELS variable has been removed, meaning the non-ISA
specialized versions of those CPU models will always be included in
gem5, except when building the NULL ISA.
In the future, a more granular config mechanism will hopefully be
implemented for *all* of gem5 and not just the CPUs, and these can be
conditional again in case you only need certain models, and want to
reduce build time or binary size by excluding the others.
Change-Id: I02fc3f645c551678ede46268bbea9f66c3f6c74b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52490
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This resource has been deprecated in favor of 'x86-ubuntu-18.04-img'. In
practise, these are the same resource (i.e., the same disk image), but
we deprecate 'x86-ubuntu-img' as 'x86-ubuntu-18.04-img' is more explicit
on what the disk image contains. Going forward we may want different
disk image resources with different Ubuntu versions, and we want it to
be clear what the user is retrieving.
Change-Id: I06b08e6b65cf431067ffda35ebd10d419068d073
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54583
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Remove the line "For use for simulation and test purposes only" in files
were AMD is the only copyright holder listed in the header. This happens
to be the case for all files where this line exists, removing it
completely from gem5.
Change-Id: I623f266b002f564301b28774f49081099cfc60fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53943
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SPEC2006 and SPEC2017 example configs require the passing of SPEC
disk image to function correctly. Prior to this commit a root partition
parameter was required. However, disk images don't necessarily have
partitions. In this case an empty string needed passed.
This patch makes the root partition parameter optional. If a disk image
does not have a root partition, it does not need specified.
Change-Id: Ic0093c70c72ab83ffaca54c8ad24245d84a5e5ba
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53846
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 CustomResource can be used to specify a custom, local disk image.
It allows the user to specify the disk root partition parameter
considerably easier than when setting a disk image through a
CustomResource.
Change-Id: I8189ad065124d028aea9fab1c7f07108aa4ce6d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53844
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 change removes the code base for SingleChannelMemory and
replaces it with MultiChannelMemory. muli_channel defines all
the classes that were defined by single_channel. Basically any
SingleChannelMemory could be thought of as a MultiChannelMemory
with 1 channel.
Change-Id: If96079d5f77be5a3ba26d2c2ddb98f5c60375cd8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53304
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Enable a gem5 system to be an SST::Component.
This change includes,
- SST::gem5Component: responsible for,
- initializing the Python environment for gem5
- instantiating gem5 SimObjects
- connecting SST::SSTResponderSubComponent to
gem5::OutgoingRequestBridge
- hanlding the gem5 event queue (no thread-synchronization)
- handling executing gem5 events
- SST::SSTResponderSubComponent: responsible for,
- receiving gem5 requests and sending the requests to
memory.
- sending responses to the corresponding
gem5::OutgoingRequestBridge.
- SST::SSTResponder: owned by SSTResponderSubComponent, the
actual actor that sends gem5's requests to memory.
- gem5::OutgoingRequestBridge: receives the requests from
gem5 and sends them to SST. This SimObject allows the initialization
requests to be cached and the receiver could query the
initialization data later on.
- gem5::SSTResponderInterface: the interface specifying how SST
communicates with gem5.
- A working example of a gem5/SST setup.
More information is available at ext/sst/README.md.
For installation instructions, please refer to ext/sst/INSTALL.md.
Change-Id: I6b81260ef825415bcfe72b8a078854f4c94de782
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50468
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This way there will always be a workload object, even if nothing needs
to be set up. This default can also be used in low_power_sweep.py,
where the workload object was just a placeholder.
This will allow required functionality like determining endianness of a
system into the workload, rather than (for instance) in the more generic
System object. This also makes accessing less essential functionality
simpler, because we don't have to detect whether the workload is there,
and can just return default, placeholder values from the StubWorkload.
Change-Id: Idfc3e75c65318d75a3eae6a19944ae1f79a2d111
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52103
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In order to fix several regression failures [1] the master/slave
terminology in src/cpu/BaseCPU.py was reintroduced [2].
This patch is addressing the issue by providing 2 different
ways of connecting cpu ports:
*) connectBus: The method assumes an object with a bus interface is
passed as an argument, therefore it tries to bind cpu ports to the
bus.mem_side_ports and bus.cpu_side_ports
*) connectAllPorts: No assumption on the port owning device is made.
The method simply accepts ports as arguments which will be directly
connected to the peer cpu ports
This will be used for example by ruby Sequencers
[1]: https://gem5.atlassian.net/browse/GEM5-775
[2]: https://gem5-review.googlesource.com/c/public/gem5/+/34495
Change-Id: I715ab8471621d6e5eb36731d7eaefbedf9663a71
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52584
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This enables an SE mode execution of binary if added a Board's
superclass.
This has been abstracted from the SimpleBoard.
The 'set_workload' function has been renamed 'set_se_binary_workload'.
This is clearer on its purpose and doesn't overlap with other
'set_workload' functions.
Change-Id: I714425a3b6b98b91e762ad076eba583bc5953ddd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52186
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This patch moves 'connect_things' to the AbstractBoard constructor,
thereby meaning it does not need to be called directly in gem5
configuration scripts. This method has been changed to private as a
result.
As boards that inherit from AbstractBoard require certain things to be
setup prior to `connect_things` being called, a new abstract function,
`_setup_board` has been created. This is called in the AbstractBoard
constructor before `connect_things` and can be overridden by boards to
setup board properties as required.
Change-Id: I558a4321b850a6b19e20b7d56d0bcae5805114b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52184
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The override parameter in the constructor has been renamed to to
'download_md5_mismatch'. This makes the purpose of this parameter
clearer.
The default value has been changed from False to True. We found in most
cases we want to re-download files if the md5 values have changes. Not
wanting to do so is the corner case. This allows us to remove a lot of
parameters from test and example scripts, included in this patch.
Change-Id: I99fc7743f5adf78bf6f4f8efc6222e6df83ac6da
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52086
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The purpose of this class is to:
* Create a standard way to set a typical kernel/disk image workload.
* Cleans up the manner in which readfile values/contents are set.
* Allows a user to specify their own kernel arguments, but still sets
sensible defaults.
As of this commit, this interface has been added to the X86Board and the
RISCVBoard.
Change-Id: I34f4c2b829f1ae5c1cae12039436cbb345a89d09
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51949
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
In order to have more fine grained control over which SLICC controllers
are part of which Ruby network in a disjoint configuration, the
create_system function in GPU_VIPER is broken up into multiple construct
calls for each SLICC machine type in the protocol. By default this does
not change anything functionally. A future config will use the construct
calls to explicitly set which network (CPU or GPU) the controller is in.
Change-Id: Ic038b300c5c3732e96992ef4bfe14e43fa0ea824
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51847
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>
This device and the file it's in have the same name as one already
defined by arm. This is basically ok when those are mutually exclusive,
but can't coexist when both ISAs can be included at the same time. This
is because the file name would put them both under
m5.objects.VirtIOMMIO, and the name of the object itself would conflict
when importing * from m5.objects.
Change-Id: I558676b7d64cc68adb2d81b070a1816aa0bea6ba
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50335
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
