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>
When allocating memory with operator new(size_t), we should also delete
that memory with operator delete(). Note that this is a generic form of
new and delete which do not construct an object in the allocated space,
or delete the object when freeing the space.
There were a number of places where we were over-allocating a structure
so that there would be room after it for other data, at least sometimes
to allocate C structures which would have a trailing array of some other
structure with an undefined size. Those structures were then being
stored in a std::unique_ptr with the default deleter, which just calls
full blown delete and not operator delete.
It seems that this is often ok, and I was not able to find anything that
spelled out in bold letters that it isn't. I did find this sentence:
"If the pointer passed to the standard library deallocation function was
not obtained from the corresponding standard library allocation function,
the behavior is undefined."
On this webpage:
https://en.cppreference.com/w/cpp/memory/new/operator_delete
This is a *little* vague, since they might mean you can't mix malloc and
delete, or new and free. Strictly interpretting it though, it could mean
you can't mix operator new with regular delete, or any other mismatched
combination.
I also found that exactly how this causes problems depends on what heap
allocator you're using. When I used tcmalloc, gem5 would segfault within
that library. When I disabled tcmalloc to run valgrind, the segfault
went away. I think this may be because sometimes you get lucky and
undefined behavior is what you actually wanted, and sometimes you don't.
To fix this problem, this change overrides the deleter on all of these
unique_ptr-s so that they use operator delete. Also, it refactors some
code in arch/x86/kvm/x86_cpu.cc so that the function that allocates
memory with operator new returns a std::unique_ptr instead of a raw
pointer. This raw pointer was always immediately put into a unique_ptr
anyway, and, in addition to tidying up the call sights slightly, also
avoids having to define a custom deleter in each of those locations
instead of once in the allocation function.
Change-Id: I9ebff430996cf603051f5baa8708424819ed8465
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52383
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Now that we're using c++17, the type_traits with a ::value member have
a _v alias which reduces verbosity. Or on other words
std::is_integral<T>::value
can be replaced with
std::is_integral_v<T>
Make this substitution throughout the code base. In places where gem5
introduced it's own similar templates, add a V alias, spelled
differently to match gem5's internal style.
gem5: :IsVarArgs<T>::value => gem5::IsVarArgsV<T>
Change-Id: I1d84ffc4a236ad699471569e7916ec17fe5f109a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48604
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, 2 and 3 levels of indentation (and a single
occurrence of 2 and 3 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *struct [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>struct X ... {
by:
<indent level>struct X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^struct ([A-Za-z].*) \{$/struct \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ struct ([A-Za-z].*) \{$/ struct \1\n \{/g'
and so on.
Change-Id: I362ef58c86912dabdd272c7debb8d25d587cd455
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39017
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation, using:
grep -nrE --exclude-dir=systemc \
"^ *class [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>class X ... {
by:
<indent level>class X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^class ([A-Za-z].*) \{$/class \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ class ([A-Za-z].*) \{$/ class \1\n \{/g'
and so on.
Change-Id: I17615ce16a333d69867b27c7bae0f4fdafd8b2eb
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39015
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than print the errno, print the result of strerror so the user
doesn't have to look up what each error code does. Don't duplicate
descriptors needlessly which have been returned by pipe(). Use panic_if
instead of if () panic. Check each call to a standard library function
instead of calling multiple and then only knowing that one of them
failed (but not which one). Close the far side of our pipes for both
the gem5 process, and the process that will become diod. Remove some
stray #undef-s which undefine macros that were never defined. Don't
try to force the descriptors going to diod to be particular numbers.
Slightly reduce nesting in the if which checks the results of fork.
Drop unnecessary \n-s in calls to panic, inform, etc. Minor spacing
related style fixes. Use nullptr instead of NULL.
Change-Id: I48d93778a1e139ef624876a0b316486aac774d7f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43083
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In python, the BARs had been configured using three arrays and a scalar
parameter. The arrays tracked the BAR value in the config, whether the
BAR was for a "legacy" IO range, and the size of the BAR, and the
scalar parameter was an offset for the "legacy" IO addresses to map
into the host physical address space. The nature of a BAR was implied
by its raw config space value, with each of the control bits (IO vs.
memory, 64 bit, reserved bits) encoded directly in the value.
Now, the BARs are represented by objects which have different types
depending on what type of BAR they are. There's one for IO, one for
memory, one for the upper 32 bits of a 64 bit BAR (so indices work
out), and one for legacy IO ranges. Each type has parameters which
are appropriate for it, and they're parameters are all grouped together
as a unit instead of being spread across all the previous values.
The legacy IO offset has been removed, since these addresses can be
offset like any other IO address. They can be represented naturally
in the config using their typical IO port numbers, and still be turned
into an address that gem5 will handle correctly in the back end.
Unfortunately, this exposes a problem in the config system where
a VectorParam can't be overwritten successfully one element at a time,
at least when dealing with SimObject classes. It might work with
actual SimObjects in a config, but I haven't tried it. If you were
to do that to, for instance, update the BARs for x86 so that they
used legacy IO ports for the IDE controller, it would complain that
you were trying to instantiate orphaned nodes. Replacing the whole
VectorParam with a new list of BAR objects seems to work, so that's
what's implemented in this change.
On the C++ side, BARs in the config space are treated as flat values
on reads, and are stored in the config structure associated with each
PCI device. On writes, the value is first passed to the BAR object,
and it has a chance to mask any bits which are fixed in hardware and
update its idea of what range it corresponds to in memory.
When sending AddrRanges up to the parent bus to set up routing, the
BARs generate each AddrRange if and only if their type has been
enabled in the config space command register. The BAR object which
represents the upper 32 bits of a 64 bit BAR does not claim to be
IO or memory, and so doesn't contribute a range. It communicates with
the BAR which represents the lower 32 bits, so that that BAR has the
whole base address.
Since the IO or memory BAR enable bits in the command register are now
handled by the PCI device base class, the IDE controller no longer has
to handle that manually. It does still need to keep track of whether
the bus master functionality has been enabled though, which it can
check when those registers are accessed.
There was already a mechanism for decoding addresses based on BARs
in the PCI device base class, but it was overly complicated and not
used consistently across devices. It's been consolidated, and used in
most places where it makes sense.
Finally, a few unnecessary values have been dropped from the base PCI
device's and IDE controller's checkpoint output. These were just local
copies of information already in the BARs, which in turn are already
stored along with the data in the device's config space.
Change-Id: I16d5f8cdf86d7a2d02a6b04d1f9e1b3eb1dd189d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35516
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The create() method on Params structs usually instantiate SimObjects
using a constructor which takes the Params struct as a parameter
somehow. There has been a lot of needless variation in how that was
done, making it annoying to pass Params down to base classes. Some of
the different forms were:
const Params &
Params &
Params *
const Params *
Params const*
This change goes through and fixes up every constructor and every
create() method to use the const Params & form. We use a reference
because the Params struct should never be null. We use const because
neither the create method nor the consuming object should modify the
record of the parameters as they came in from the config. That would
make consuming them not idempotent, and make it impossible to tell what
the actual simulation configuration was since it would change from any
user visible form (config script, config.ini, dot pdf output).
Change-Id: I77453cba52fdcfd5f4eec92dfb0bddb5a9945f31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35938
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change replaces the __attribute__ syntax with the now standard [[]]
syntax. It also reorganizes compiler.hh so that all special macros have
some explanatory text saying what they do, and each attribute which has a
standard version can use that if available and what version of c++ it's
standard in is put in a comment.
Also, the requirements as far as where you put [[]] style attributes are
a little more strict than the old school __attribute__ style. The use of
the attribute macros was updated to fit these new, more strict
requirements.
Change-Id: Iace44306a534111f1c38b9856dc9e88cd9b49d2a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35219
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
VirtIO devices currently request their endianness from the System
object. Instead of explicitly querying the system for its endianness,
expose the device's endianness as a param. This param defaults to the
endianness of a parent object using the Parent proxy (in practice the
system).
Change-Id: If4f84ff61f4d064bdd015a881790f5af03de6535
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33296
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
isa_traits.hh used to have much more in it, but now it only has
PageShift, PageBytes, and (for now) the guest endianness. These values
should only be retrieved from the System class generally speaking, so
only the system class should include arch/isa_traits.hh.
Some gpu compute related files need PageBytes or PageShift. Even though
those files don't advertise their ISA dependence, they are tied to x86.
In those files, they can include arch/x86/isa_traits.hh.
The only other file which legitimately needs arch/isa_traits.hh is the
decoder cache since it uses PageBytes to size an array.
Change-Id: I12686368715623e3140a68a7027c136bd52567b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33203
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These classes now track what endianness they're supposed to use
explicitly, initially set by the getGuestByteOrder accessor on the
system object. In the future, if the endianness depends on the
version of the VirtIO spec as the comment suggest, it will be easier
to dynamically set the endianness in the various structures based on
the version being used,
Since there isn't anything special about the virt IO versions of these
converters other than their types, and since the endianness conversion
infrastructure can be taught how to convert new types, the code was
switched over to using the standard htog and gtoh but with the
explicit byte order provided.
This also gets rid of the final use of TheISA in the dev directory.
Change-Id: I9345e3295eb27fc5eb87e8ce0d8d424ad1e75d2d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22273
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The importer in Python 3 doesn't like the way we import SimObjects
from the global namespace. Convert the existing SimObject declarations
to import from m5.objects. As a side-effect, this makes these files
consistent with configuration files.
Change-Id: I11153502b430822130722839e1fa767b82a027aa
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15981
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Generally speaking, the endianness of the data devices provide or
accept is dependent on the device and not the ISA the system
executes. This change makes the devices in dev pick an endianness
rather than using the guest's.
For the ISA bus and the UART, accesses are byte sized and so endianness
doesn't matter. The ISA and PCI busses and the devices which use them
are defined to be little endian.
Change-Id: Ib0aa70f192e1d6f3b886d9f3ad41ae03bddb583f
Reviewed-on: https://gem5-review.googlesource.com/c/13462
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The UART models currently assume that they are always wired to a
terminal. While true at the moment, this isn't necessarily a valid
assumption. This change introduces the SerialDevice class that defines
the interface for serial devices. Currently, Terminal is the only
class that implements this interface.
Change-Id: I74fefafbbaf5ac1ec0d4ec0b5a0f4b246fdad305
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/4289
Reviewed-by: Gabe Black <gabeblack@google.com>
* When dispatching multiple gem5 simulations at once, they race
for the socket id, resulting in a panic when calling 'bind'. To
avoid this problem, the socket id is now created before the diod
process is created. In case of a race, a panic is called in the
gem5 process, whereas before the panic was called in the diod
process where it didn't have any effect.
* In some cases killing the diod process in terminateDiod() using
only SIGTERM failed, so a call using SIGKILL is added.
Change-Id: Ie10741e10af52c8d255210cd4bfe0e5d761485d3
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2821
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
With the change we explicitly update the types for the VirtIO bit
masks to be Addr (uint64_t). By changing this, we ensure type
promotion where it is needed. Therefore, this fixes issues where, in
certain situations, address calculations were performed in 32-bits,
resulting in overflows.
Change-Id: I5c5c3f9a3f94e806812282da01268e18ae0d2d39
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3968
This commit adds support for diod to use a unix socket, rather
than a TCP port. We don't rely on the IP-based connection as we
directly use pipes to interact with diod. This allows it to work
on any system, even if the specific port is taken by another diod
instance (or similar). Secondly, the Unix socket could in theory
be used to debug. However, this functionality has not been
tested.
Change-Id: I616e0ad8768da1dfc867de3af98cdfbb22a72d63
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2820
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
When setting the size of a PCI BAR, the kernel only supports powers of
two (as per the PCI spec). Previously, the size was incorrectly read
by the kernel, and the address ranges assigned to the PCI devices
could overlap, resulting in gem5 crashes. We now round up to the next
power of two.
Kudos to Sergei Trofimov who helped to debug this issue!
Change-Id: I54ca399b62ea07c09d4cd989b17dfa670e841bbe
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-by: Sergei Trofimov <sergei.trofimov@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2580
Reviewed-by: Paul Rosenfeld <prosenfeld@micron.com>
VirtIO transport interfaces always expect a VirtIO device
pointer. However, there are cases (in particular when using VirtIO's
MMIO interface) where we want to instantiate an interface without a
device. Add a dummy device using VirtIO device ID 0 and no queues to
handle this use case.
Change-Id: I6cbe12fd403903ef585be40279c3b1321fde48ff
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Sudhanshu Jha <sudhanshu.jha@arm.com>
Reviewed-by: Rekai Gonzalez Alberquilla <rekai.gonzalezalberquilla@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2325
Reviewed-by: Weiping Liao <weipingliao@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
VirtIO spec < 1.0 demands IOREG to be used on PCI and not memory mapped.
Set the correct bit on the PCI address accordingly.
Committed by Jason Lowe-Power <power.jg@gmail.com>
