In FS mode offsets for HSA queues are determined by the driver and
cannot be linearly assigned as they are in SE mode. Add plumbing to pass
the offset of a queue to the HSA packet processor and then to HW
scheduler.
A mapping to/from queue ID <-> doorbell offset are also needed to be
able to unmap queues. ROCm 4.2 is fairly aggressive about context
switching queues, which results in queues being constantly mapped and
unmapped.
Another result of remapping queues is the read index is not preserved in
gem5. The PM4 packet processor will write the currenty read index value
to the MQD before the queue is unmapped. The MQD is written back to
memory on unmap and re-read on mapping to obtain the previous value.
Some helper functions are added to be able to restore the read index
from a non-zero value.
Change-Id: I0153ff53765daccc1de23ea3f4b69fd2fa5a275f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53076
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add the page table walker, page table format, TLB, TLB coalescer, and
associated support in the AMDGPUDevice. This page table format used the
hardware format for dGPU and is very different from APU/GCN3 which use
the X86 page table format.
In order to support either format for the GPU model, a common
TranslationState called GpuTranslation state is created which holds the
combined fields of both the APU and Vega translation state. Similarly
the TlbEntry is cast at runtime by the corresponding arch files as they
are the only files which touch the internals of the TlbEntry. The GPU
model only checks if a TlbEntry is non-null and thus does not need to
cast to peek inside the data structure.
Change-Id: I4484c66239b48df5224d61caa6e968e56eea38a5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51848
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 powered on, the "passed self test" bit should not be set. It should
only be set once the I8042 has actually been told to do a self test.
Also the mouse and keyboard should be disabled. With them disabled their
interrupts won't matter, but we might as well leave those disabled as
well.
Change-Id: Ief1ab30365a0a8ea0a116e52c16dcccf441515ec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55805
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now that the I8259's vector is reported using a special memory access,
the getVector method doesn't need to be accessible outside of the class.
It's still useful internally though, since it nicely encapsulates what
should happen when an INTA signal is received.
Change-Id: I7da7c1f18fac97ffc62c965978f53fb4c5430de3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55698
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In a real system, once a CPU receives an interrupt of type ExtInt, it
will send an INTA message out to the I8259 sytle interrupt controllers
to read the vector for that interrupt. In ye-olden-times, that would
literally mean the I8259 would be in charge of the bus and would write
the eight bit vector for the CPU to read. In more modern systems, the
vector is transported on the system interconnect using a special
message.
To better approximate a real system, and to make the interrupt
controllers more modular and agnostic (so the IO APIC doesn't have a
I8259 pointer within it, for instance), this change adds a new special
address which the I8259 can respond to on reads which will act as if it
received an INTA message, and the read data will be the interrupt
vector.
Only the master controller, or a single device, will respond to this
address, and because of its value and the fact that it's beyond the end
of the 16 bit IO port address space's effective range but still within
it, that address won't be generated by any other activity other than
possibly a bogus address.
Also by putting the special address in the IO port address space, that
will make it easier to ensure that it's within the range of addresses
which are routed towards the I8259 which operates off the IO port bus.
This address is not yet actually used by the IO APIC or local APIC but
will be shortly.
Change-Id: Ib73ab4ee08531028d3540570594c552f39053a40
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55694
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The x86 version is basically just a specialization of the base IO port
version of the QEMU firmware configuration device, with the port
addresses set for x86.
The E820 entry type is x86 specific, and is a way to pass an E820 memory
map to firmware which doesn't have another way to figure out where
memory is. This would be for firmware like SeaBIOS which is itself
responsible for publishing an E820 map, but it needs somewhere to get
that information from in the first place. This mechanism is one it
supports natively.
This entry type reuses the E820Entry SimObjects which were defined a
long time ago for passing to a Linux FS workload. It doesn't use their
ability to write themselves out to guest memory, and just uses them as a
transport for their address, size and type properties.
Change-Id: Ifff214f5fc10bd7d0a2a0acddad4fc00dd65f67d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55628
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This artificial device is provided by QEMU inside their emulated
machines to feed extra configuration information to the system firmware,
or even to the operating system if it chose to use it. The behavior of
this device is explained in the docs/specs/fw_cfg.txt file in the QEMU
source.
This implementation currently supports the traditional interface, and
does not support the DMA based interface, although it probably wouldn't
be that hard to expand it to in the future.
The interface exposes individual entries which can optionally (and
usually) have paths associated with them that you can look up in a
directory type entry which has a fixed index. There are some entries
which are built into the device itself, which are the ID, signature and
directory entries, but the rest can be set up in the config scripts.
To make it easier to add new entries which are not from config scripts,
aka the ones that are hard coded in C++ and built into the device, the
actual entries themselves are not SimObjects, but it's easy to create a
SimObject wrapper which will spit them out for the device to consume.
Other items can be added to the device manually without generating them
with SimObjects.
Entries can have fixed or automatically generated indices. All entries
have a "path" in the sense that they have a name, but as a minor
deviation from what the QEMU documentation says, a "path" which begins
with a "." is not exported in the directory. This is purposefully
reminiscent of the unix style hidden file mechanism, where files or
directories who's names begin with "." are not normally shown by ls.
There are two different styles of this device, one which is IO port
based, and one which is MMIO based. Which to use depends on the
architecture, where x86 currently uses the IO scheme and ARM uses the
MMIO scheme. The documentation doesn't say what other ISAs use, if any
other ones support this interface, but I'd assume the MMIO version.
These are split out because the rules for how they work are subtly
different, but they share a lot of common machinery under the hood.
In most cases where somebody tries to talk to the device in an unusual
way, for instance accessing a register with an incomplete width or at an
offset, the device will just report all zeroes. The behavior in those
cases isn't specified, in many cases doesn't make sense based on the
design of the device, and doesn't seem to be depended on in the limited
use case I looked at.
Change-Id: Ib81ace406f877b298b9b98883d417e7d673916b5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55627
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This is essentially the same as the normal one, except it sets its
ProgIF bits to show that it works in compatibility mode only, with fixed
IO ports and fixed IRQs that it operates with which are outside of the
scope of the normal PCI mechanisms.
Change-Id: I69d04f5c9444e7e227588b96b7dd4123b2850e23
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55586
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
This command is one of two that should be implemented by ATAPI devices.
An ATAPI device are essentially optical devices which use SCSI commands
which are transported over ATA using two special commands, a PACKET
command which actually sends the SCSI commands, and an IDENTIFY command
which is basically the same as the ATA IDENTIFY command but which is
only implemented on ATAPI devices. In order to determine if the device
connected to an IDE controller is an optical drive or a regular ATA hard
drive, software can send the ATAPI_IDENTIFY_DEVICE command and see if
gets an appropriate response.
In gem5, this command was originally not implemented by the IDE disk
model. If a driver attempted to send it, the gem5 model would panic and
kill the simulation. To fix that problem, that command was added to the
list of supported commands and just made a synonym for the ATA IDENTIFY
command since they have essentially the same response.
Unfortunately, this makes all ATA devices look like ATAPI devices, which
is not what we have implemented.
Instead, when we get this command, what we *should* do, as far as I can
tell by reading this:
http://users.utcluj.ro/~baruch/media/siee/labor/ATA-Interface.pdf
is to set the ERR bit in the status register, and then set the ABRT bit
in the error register to indicate that the command was not implemented.
I've attempted to implement that into the model with this change by
setting those bits as described, and then setting the "action" member to
be ACT_CMD_ERROR. I think that action is there primarily to support
cancelled transfers, but it seems like it has the desired effect(?).
Since the error bits are not really explicitly set or managed by the
model in most cases, this change also adds a little bit of code at the
top of startCommand which clears them to zero. These bits are supposed
to "contain the status of the last command executed", and if we're
starting a new command, the error bits no longer apply.
I'm confident that conceptually this is how the ATAPI_IDENTIFY_DEVICE
command should behave in our model, at least unless we decide to
implement real ATAPI models which actually accept SCSI commands, etc.
I'm less confident that I've modified the model to actually implement
that behavior, but as far as I can tell it doesn't seem to have broken
anything, and now SeaBIOS no longer things our disk model is a CDROM
drive.
Change-Id: I2c0840e279e9caa89c21a4e7cbdbcaf6bccd92ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55523
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
A (another) weird/terrible quirk of the architecture of the PC is that
the the highest order bit of the value which selects a register to read
from the CMOS NVRAM/RTC is stolen and repurposed to enable/disable NMIs
since the 286, if the internet is to be believed.
Fortunately We don't currently attempt to generate an NMI anywhere, and so
this bit won't do anything in gem5 currently.
Unfortunately if we treat this value as the real offset without masking
off this bit, if software attempts to disable NMIs with it, it will
trigger an out of bounds assert in the CMOS device.
This change makes the CMOS device slightly smarter and has it maintain
but ignore the NMI disabling bit.
Change-Id: I8d7d0f1b0aadcca2060bf6a27931035859d66ca7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55244
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GICv3 register interface is different from the GICv2 one: from
the presence of redistributor registers up to the system register
implementation of the cpu-interface
We therefore make the current BaseGicRegisters interface GICv2 specific.
We will define a different Gic3Registers interface for GICv3 state
transfer
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I42f15f48cab6e26aaf519e13c2ce70f661801117
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55703
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Disks now track the channel they're attached to so that that doesn't
have to be rediscovered by comparing points, channels know if they're
primary or secondary, and interrupts will now set the interrupt bit of
the channel they're associated with instead of always the primary.
Also the interrupt mechanism was adjusted slightly so that it's
implemented by a virtual function which knows whether the interrupt came
from the primary or secondary channel. That will make it possible to
implement separate interrupts, as required by the compatibility mode
which can be used with x86.
Change-Id: Ic5527c238ef7409153e80e4ab843a50be6e452c5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55584
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
De-virtualize updateIntState and replace it with the new blockIntUpdate
in the MuxingKvmGic class.
The monolithic updateIntState is GicV2 specific and it is not compatible
with the more complex IRQ update logic in GicV3, which is delegating the
update to the destributor/redistributor/cpuinterface classes
Rather than stubbing the update function the MuxingKvmGic class, we
override the blockIntUpdate to return true in case a KVM gic is in use.
This is loosening the interface, not restricting any GIC implementation
to a specific update interface/design
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: Ib8d9c99b720c779a2255ac47ee2a655ff281581d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55609
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
There are two entities setting up the IOAPIC when the simulation is
started, the IOAPIC itsef, and the PC platform object. It's probably not
a good idea (and definitely confusing) to have this initialization
happening in two places.
For now at least, lets make the PC platform object mask the IOAPIC lines
at startup like the IOAPIC is doing. This will help prevent spurious
interrupts from being delivered to the CPU during startup.
Change-Id: I10f455d8e0fca28ddaf772c224a32c1f5f2dd37b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55452
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This command can trigger count latching for any of the PIT channels
together with a single command, and can also latch a status byte. The
status byte is not implemented here, but there is already functionality
for latching the count which this can use.
Change-Id: Ic2ad7c73d0c521fdd6fe5f62cb478c6718f3b90c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55283
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If there really are no c++ sim_objects in the file, then sim_objects can
be set to [] which it used to default to.
This way, if someone hasn't remembered to update their SConscript files
for the new sim_objects and enums parameters, this will give them some
indication what's wrong, rather than the build just failing later.
Change-Id: Ic1933f7b9dfff7dd7e403c6c84f1f510c8ee8c72
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54203
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.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>
