NMI is platform dependent according to riscv spec, so we intentionally
propose a very minimal design that doesn't give user any new accessible
register to interact with the NMI mechanism.
In current design, the NMI reset vector is fixed to 0x0 and always set
mcause to zero. mret from NMI handler is still possible, but it's up to
the user to detect whether a M-mode trap handler is interrupted and to
recover from it (if at all possible).
1. Add new fault type to represent NMI fault
2. Add non-standard registers to save the status of NMI
a. nmivec[63:2] = NMI reset vector address
b. nmie[0:0] = is NMI enabled = not in NMI handler
c. nmip[0:0] = is NMI pending
3. Add new function in RiscvInterrupts to raise/clear NMI
Bug: 200169094
Test: None
Change-Id: Ia81e1c9589bc02f0690d094fff5f13412846acbe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52363
Reviewed-by: Yu-hsin Wang <yuhsingw@google.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>
When calling a method in a superclass, you can/should use the super()
method to get a reference to that class. The python 2 version of that
method takes two parameters, the current class name, and the "self"
instance. The python 3 version takes no arguments. This is better for a
at least three reasons.
First, this version is less verbose because you don't have to specify
any arguments.
Second, you don't have to remember which argument goes where (I always
have to look it up), and you can't accidentally use the wrong class
name, or forget to update it if you copy code from a different class.
Third, this version will work correctly if you use a class decorator.
I don't know exactly how the mechanics of this work, but it is referred
to in a comment on this stackoverflow question:
https://stackoverflow.com/questions/681953/how-to-decorate-a-class
Change-Id: I427737c8f767e80da86cd245642e3b057121bc3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52224
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This will let callers create a separate copy of a PCState class
instance. This makes it more explicit when creating copies of a PCState
to make sure the programmer is more aware, and avoids having to know
what the actual type is to make a copy.
Change-Id: I728a278afdb55b800c753a5b7f65f62f4a80c043
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52035
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
These helpers will make it easier to cast a PCStatePtr into an ISA
specific class with less syntactic fluff. They are currently implemented
with a static_cast for performance reasons, but could be implemented
with a dynamic_cast and an assert for extra debugging if you were
willing to pay the performance overhead. In the future this might be
switched/enabled as an extra debugging mode, like how locking can have
extra checks enabled in the Linux kernel.
Change-Id: Ibc2443c6b991ebc2e5d0240a88436849cb6de2b9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52033
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This class has a lot of common functionality which all PCState classes
use, but in order to make it a true base class which provides the
complete interface for PCState-s throughout gem5, all its methods would
need to become virtual. That doesn't have to be the case today because
we use the literal full ISA specific PC class directly, but we need to
move away from that.
This change leaves PCStateBase empty, since we don't know what will need
to be accessible in base classes through a common/virtual interface.
Also, move methods which do not depend on the InstWidth template
parameter out of SimplePCState and into PCStateCommon. This avoids
having duplicate methods with the same contents which don't depend on
InstWidth.
Change-Id: I31309c4f35e897db1bc8318439fae1567a82b35e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52031
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Earl Ou <shunhsingou@google.com>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
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>
This simplifies the O3 CPU, and removes special cases around how vector
registers are handled. Now ARM is responsible for maintaining its
different register personalities internally.
Also, this re-establishes the invariant that registers are indexed as
complete, opaque entities with no internal structure, at least as far as
the CPU is concerned.
To make sure the KVM CPU sees the correct state, we need to sync over
the vector registers if we're in 32 bit mode when moving state to or
from gem5's ThreadContext.
Change-Id: I36416d609310ae0bc50c18809f5d9e19bfbb4d37
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49147
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The x86 KVM CPU had been in the cpu/kvm directory, while the arm CPU was
inconsistently in the arch/arm directory.
This change moves the x86 CPU to be in arch/x86, restoring consistency.
This location will make the KVM support more modular, by not having the
x86 CPU implementation right alongside the generic implementation.
Change-Id: Ia13151f843df8f8877bfef5ff620825877d3dffa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52085
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This translation generator is returned by the new version of the
TranslateFunctional method which translates a region rather than a
single address. That method is currently virtual with a default
implementation which is not overloaded, but the plan is for the other
MMUs to override that method and inject their own page size minimally.
In the future, the MMUTranslationGen class and the implementations in
the MMUs may be updated so that they can, for instance, handle varying
page sizes across a single translation.
Change-Id: I39479f0f0e8150fc6e3e1a7097a0c8bd8d22d4e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50759
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The arch implies gem5 lib, and not the other way around. Or in other
words, if, for example, x86 is the ISA, the having the tag 'x86 isa'
would imply that that file also has the tag 'gem5 lib'. Having the tag
'gem5 lib' would not imply 'x86 isa'.
This worked out because when testing for a single tag, we were using
with_any_tags, and 'gem5 lib' would expand to 'gem5 lib' and 'x86 isa'.
Then we would match files which were non-specific and used 'gem5 lib',
or files which had more specifically used 'x86 isa' only. Files which
used, for instance, 'arm isa', would not meet either criteria of the
implied "or".
Change-Id: I301d1bbbbcac1594371584d4b0d5d291b7b77fc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51827
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Otherwise, SCons may discover an include which is guarded with BUILD_GPU
(like GPUCoalescer in mem/ruby/profiler/Profiler.cc), but not understand
that BUILD_GPU is not true. It will then follow the includes and find
generated headers which it will then generate, specifically X86 headers
for X86TLB and X86Pagetable param structs.
If not using x86, for instance if building the NULL isa, it may not be
possible to generate those headers because those objects are not visible
to SCons.
Change-Id: I955d0ef6ffb146eeb99bb052d29abe835cac5d9a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51829
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When an object is a field in a union, it's the programmer's
resposibility to destroy it from the union's destructor. We can simply
neglect to do that and avoid having to use new to create the flags.
Also, we can define the flags as inline variables (a c++17 feature), and
then create a constexpr references to them. This lets us refer to debug
flags in constexpr objects, although we can't interact with them at, for
instance, construciton time or we'd lose our own constexpr-ness since
the actual object is not constexpr.
In c++20 we would hypothetically be able to use constexpr with new and
delete, but there may be additional restrictions that would make this
particular use impossible. Also this avoids leaking memory, which, even
though it's intentional, may confuse tools like valgrind.
Also, we need to ensure that all headers are included in some source
file so that they exist in the final executable, so that they show up in
the help, can be enabled/disabled, etc.
Change-Id: Ia43111d938e7af7140b1c17dd68135f426d0a1e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49783
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jui-min Lee <fcrh@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We shouldn't print all TLB stats regardless of their value
For example there is no need to print the number of
read/write hits/misses/accesses in a instruction only TLB as
it will always inevitably be zero
With this patch we are flagging them as nozero, in order
to suppress their printing in the final stats file.
We are still printing them (regardless of their value) in the
unified TLB type
Change-Id: I54e57d856ceb451f6bacdd175a61768d030862aa
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51667
Tested-by: kokoro <noreply+kokoro@google.com>
We want to insist that the fast model libraries are the static versions
so they don't have to be found on non-system paths at run time, but we
don't need or want to do the same for system libraries which are from
standard paths on the host system.
Split the set of libraries fast model adds to the build into ones that
come from fast model itself, and ones it needs which should be
provided by the system. The ones from fast model itself should still
go through staticify, but the system libraries should be passed to the
compiler generically so it can pick which version it wants.
Change-Id: I222c94f8117143b86377150e686a4af669a994fe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51627
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
