History log of /gem5/src/dev/x86/intdev.cc
Revision Date Author Comments
# 14295:16025a55b380 11-Sep-2019 Gabe Black <gabeblack@google.com>

x86: Templatize the IntMasterPort.

This makes the IntMasterPort usable with any class, making it possible
to avoid inheriting from IntDevice.

It also makes IntMasterPort inherit directly from QueuedMasterPort,
skipping over MessageMasterPort.

Change-Id: I9d218556c838ea567ced5f6fa4d57a3ec9d28d31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20821
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>


# 14291:722551795497 06-Sep-2019 Gabe Black <gabeblack@google.com>

dev, x86: Delete the now unused X86 specific interrupt pins/lines.

Change-Id: I3915f0ad673119b551dcc4c5cedec180a9b88735
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20702
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>


# 11144:90eeefe7e341 29-Sep-2015 Joel Hestness <jthestness@gmail.com>

arch, x86: Delete packet in IntDevice::recvResponse

IntDevice::recvResponse is called from two places in current mainline: (1) the
short circuit path of X86ISA::IntDevice::IntMasterPort::sendMessage for atomic
mode, and (2) the full request->response path to and from the x86 interrupts
device (finally called from MessageMasterPort::recvTimingResp). In the former
case, the packet was deleted correctly, but in the latter case, the packet and
request leak. To fix the leak, move request and packet deletion into IntDevice
inherited class implementations of recvResponse.


# 9807:63d7362bbdf2 11-Jul-2013 Steve Reinhardt <stever@gmail.com>

dev: consistently end device classes in 'Device'

PciDev and IntDev stuck out as the only device classes that
ended in 'Dev' rather than 'Device'. This patch takes care
of that inconsistency.

Note that you may need to delete pre-existing files matching
build/*/python/m5/internal/param_* as scons does not pick up
indirect dependencies on imported python modules when generating
params, and the PciDev -> PciDevice rename takes place in a
file (dev/Device.py) that gets imported quite a bit.

Committed by: Nilay Vaish <nilay@cs.wisc.edu>


# 9163:3b5e13ac1940 22-Aug-2012 Andreas Hansson <andreas.hansson@arm.com>

Port: Extend the QueuedPort interface and use where appropriate

This patch extends the queued port interfaces with methods for
scheduling the transmission of a timing request/response. The methods
are named similar to the corresponding sendTiming(Snoop)Req/Resp,
replacing the "send" with "sched". As the queues are currently
unbounded, the methods always succeed and hence do not return a value.

This functionality was previously provided in the subclasses by
calling PacketQueue::schedSendTiming with the appropriate
parameters. With this change, there is no need to introduce these
extra methods in the subclasses, and the use of the queued interface
is more uniform and explicit.


# 8922:17f037ad8918 30-Mar-2012 William Wang <william.wang@arm.com>

MEM: Introduce the master/slave port sub-classes in C++

This patch introduces the notion of a master and slave port in the C++
code, thus bringing the previous classification from the Python
classes into the corresponding simulation objects and memory objects.

The patch enables us to classify behaviours into the two bins and add
assumptions and enfore compliance, also simplifying the two
interfaces. As a starting point, isSnooping is confined to a master
port, and getAddrRanges to slave ports. More of these specilisations
are to come in later patches.

The getPort function is not getMasterPort and getSlavePort, and
returns a port reference rather than a pointer as NULL would never be
a valid return value. The default implementation of these two
functions is placed in MemObject, and calls fatal.

The one drawback with this specific patch is that it requires some
code duplication, e.g. QueuedPort becomes QueuedMasterPort and
QueuedSlavePort, and BusPort becomes BusMasterPort and BusSlavePort
(avoiding multiple inheritance). With the later introduction of the
port interfaces, moving the functionality outside the port itself, a
lot of the duplicated code will disappear again.


# 8914:8c3bd7bea667 22-Mar-2012 Andreas Hansson <andreas.hansson@arm.com>

MEM: Split SimpleTimingPort into PacketQueue and ports

This patch decouples the queueing and the port interactions to
simplify the introduction of the master and slave ports. By separating
the queueing functionality from the port itself, it becomes much
easier to distinguish between master and slave ports, and still retain
the queueing ability for both (without code duplication).

As part of the split into a PacketQueue and a port, there is now also
a hierarchy of two port classes, QueuedPort and SimpleTimingPort. The
QueuedPort is useful for ports that want to leave the packet
transmission of outgoing packets to the queue and is used by both
master and slave ports. The SimpleTimingPort inherits from the
QueuedPort and adds the implemention of recvTiming and recvFunctional
through recvAtomic.

The PioPort and MessagePort are cleaned up as part of the changes.


# 8855:74490e94da0c 24-Feb-2012 Andreas Hansson <andreas.hansson@arm.com>

MEM: Prepare mport for master/slave split

This patch simplifies the mport in preparation for a split into a
master and slave role for the message ports. In particular,
sendMessageAtomic was only used in a single location and similarly so
sendMessageTiming. The affected interrupt device is updated
accordingly.


# 8851:7e966326ef5b 24-Feb-2012 Andreas Hansson <andreas.hansson@arm.com>

MEM: Move port creation to the memory object(s) construction

This patch moves all port creation from the getPort method to be
consistently done in the MemObject's constructor. This is possible
thanks to the Swig interface passing the length of the vector ports.
Previously there was a mix of: 1) creating the ports as members (at
object construction time) and using getPort for the name resolution,
or 2) dynamically creating the ports in the getPort call. This is now
uniform. Furthermore, objects that would not be complete without a
port have these ports as members rather than having pointers to
dynamically allocated ports.

This patch also enables an elaboration-time enumeration of all the
ports in the system which can be used to determine the masterId.


# 8711:c7e14f52c682 17-Jan-2012 Andreas Hansson <andreas.hansson@arm.com>

MEM: Separate queries for snooping and address ranges

This patch simplifies the address-range determination mechanism and
also unifies the naming across ports and devices. It further splits
the queries for determining if a port is snooping and what address
ranges it responds to (aiming towards a separation of
cache-maintenance ports and pure memory-mapped ports). Default
behaviours are such that most ports do not have to define isSnooping,
and master ports need not implement getAddrRanges.


# 7913:70b56a9ac1b2 07-Feb-2011 Brad Beckmann <Brad.Beckmann@amd.com>

dev: fixed bugs to extend interrupt capability beyond 15 cores


# 7899:38eca2df1124 07-Feb-2011 Joel Hestness <hestness@cs.utexas.edu>

MessagePort: implement the virtual recvTiming function to avoid double pkt delete

Double packet delete problem is due to an interrupt device deleting a packet that the SimpleTimingPort also deletes. Since MessagePort descends from SimpleTimingPort, simply reimplement the failing code from SimpleTimingPort: recvTiming.


# 6138:6cbdd76b93db 26-Apr-2009 Gabe Black <gblack@eecs.umich.edu>

X86: Tell the function that sends int messages who to send to instead of figuring it out itself.


# 6064:46d327d42036 19-Apr-2009 Gabe Black <gblack@eecs.umich.edu>

X86: Add a function which gets called when an interrupt message has been delivered.


# 6045:214461cb8abe 19-Apr-2009 Gabe Black <gblack@eecs.umich.edu>

X86: Make code that sends an interrupt from the IO APIC available for IPIs.


# 5827:ac2c268bf4f1 01-Feb-2009 Gabe Black <gblack@eecs.umich.edu>

X86: Rework interrupt pins to allow one to many connections.


# 5633:e1605152cc54 11-Oct-2008 Gabe Black <gblack@eecs.umich.edu>

X86: Create the IntDev and IntPin system.

The IntDev class is a base for anything that supports IntPins. IntPins allow
devices to generically trigger interrupts on a particular pin of an IntDev
device without having to know what the device is or what pin they're attached
to.