| Age | Commit message (Collapse) | Author |
|---|
|
LongModeAddressSize was used by kernel 2.6.28.4 for physical address
validation, if not properly implemented, PCI resource allocation may
failed because of ioremap failed:
- linux-2.6.28.4/arch/x86/mm/ioremap.c:27-30
27 static inline int phys_addr_valid(unsigned long addr)
28 {
29 return addr < (1UL << boot_cpu_data.x86_phys_bits);
30 }
- linux-2.6.28.4/arch/x86/kernel/cpu/common.c:475-482
475 #ifdef CONFIG_X86_64
476 if (c->extended_cpuid_level >= 0x80000008) {
477 u32 eax = cpuid_eax(0x80000008);
478
479 c->x86_virt_bits = (eax >> 8) & 0xff;
480 c->x86_phys_bits = eax & 0xff;
481 }
482 #endif
- linux-2.6.28.4/arch/x86/mm/ioremap.c:209-214
209 if (!phys_addr_valid(phys_addr)) {
210 printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
211 (unsigned long long)phys_addr);
212 WARN_ON_ONCE(1);
213 return NULL;
214 }
This patch return 0x0000ffff for LongModeAddressSize, which guarantee phys_addr_valid never failed.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
|
|
This patch force IO device to be mapped to 0xC0000000-0xFFFF0000 by
reserve anything between the end of memory and 3GB if memory is less
than 3GB. It also statically bridge these address range to the IO bus,
which guaranty access to pci address space will pass though bridge to
iobus.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
|
|
This patch assign bus_id=0 to PCI bus and bus_id=1 to ISA bus for
X86 platform. Because PCI device get config space address using
Pc::calcPciConfigAddr() which requires "assert(bus==0)".
This fixes PCI interrupt routing and discovery on Linux.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
|
|
fix draining bug where multiple cores hit max_insts_any_thread simultaneously
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
|
|
The validity check is being changed from < to <= since the end of the range
is considered to be a part of it.
|
|
|
|
|
|
This patch takes the final step in integrating DRAMPower and adds the
appropriate calls in the DRAM controller to provide the command trace
and extract the power and energy stats. The debug printouts are still
left in place, but will eventually be removed.
At the moment the DRAM power calculation is always on when using the
DRAM controller model. The run-time impact of this addition is around
1.5% when looking at the total host seconds of the regressions. We
deem this a sensible trade-off to avoid the complication of adding an
enable/disable mechanism.
|
|
This patch adds a class to wrap DRAMPower Library in gem5.
This class initiates an object of class MemorySpecification
of the DRAMPower Library, passes the parameters from DRAMCtrl.py
to this object and creates an object of drampower library using
the memory specification.
|
|
This patch adds missing timing and current parameters to the existing
DRAM configs. These missing timing and current parameters are required
by DRAMPower for the DRAM power calculations. The missing values are
datasheet values of the specified DRAMs, and the appropriate
references are added for the variuos configs.
|
|
This patch prunes the DDR3 config that was initially created to match
the default config of DRAMSim2. The config is not complete as it is,
and to avoid having to maintain it, the easiest way forward is to
simply prune it. Going forward we are adding power number etc to the
other configurations.
|
|
This patch adds the open-source (BSD 3-clause) tool DRAMPower, commit
8d3cf4bbb10aa202d850ef5e5e3e4f53aa668fa6, to be built as a part of the
simulator. We have chosen this specific version of DRAMPower as it
provides the necessary functionality, and future updates will be
coordinated with the DRAMPower development team. The files added only
include the bits needed to build the library, thus excluding all
memory specifications, traces, and the stand-alone DRAMPower
command-line tool.
A future patch includes the DRAMPower functionality in the DRAM
controller, to enable on-line DRAM power modelling, and avoid using
post-processing of traces.
|
|
This patch adds the Python parameter type Current, which is used for
the DRAM power modelling (to start with). With this addition we avoid
implicit unit assumptions.
|
|
The Ozone CPU is now very much out of date and completely
non-functional, with no one actively working on restoring it. It is a
source of confusion for new users who attempt to use it before
realizing its current state. RIP
|
|
|
|
This patch adds a number of asserts to the cache, checking basic
assumptions about packets being requests or responses.
|
|
This patch changes the packet queue such that when scheduling a send,
the queue is allowed to move the event forward.
|
|
Another bunch of issues addressed.
|
|
Some additional type checking to avoid future issues.
|
|
Some incorrect casting to IntRegIndex, and a few uninitialized members
in the i8254xGBe device.
|
|
As a result of the fixes, the full-system dual-core ARM regressions
are slightly changed. Hopefully this also means there will no longer
be any discrepancies between the results observed on different hosts.
|
|
This patch fixes the runtime errors highlighted by the undefined
behaviour sanitizer. In the end there were two issues. First, when
rotating an immediate, we ended up shifting an uint32_t by 32 in some
cases. This case is fixed by checking for a rotation by 0
positions. Second, the Mrc15 and Mcr15 are operating on an IntReg and
a MiscReg, but we used the type RegRegImmOp and passed a MiscRegIndex
as an IntRegIndex. This issue is resolved by introducing a
MiscRegRegImmOp and RegMiscRegImmOp with the appropriate types.
With these fixes there are no runtime errors identified for the full
ARM regressions.
|
|
This patch optimises the passing of StaticInstPtr by avoiding copying
the reference-counting pointer. This avoids first incrementing and
then decrementing the reference-counting pointer.
|
|
Fix a number few minor issues to please gcc 4.9.1. Removing the
'-fuse-linker-plugin' flag means no libraries are part of the LTO
process, but hopefully this is an acceptable loss, as the flag causes
issues on a lot of systems (only certain combinations of gcc, ld and
ar work).
|
|
|
|
|
|
When _masterPort is null, a message to that effect is
more helpful than a segfault.
|
|
Add some missing initialisation, and fix a handful benign resource
leaks (including some false positives).
|
|
|
|
|
|
This patch bumps the stats to reflect the addition of the snoop filter
and snoop stats, the change from bus to crossbar, and the updates to
the ARM regressions that are now using a different CPU and cache
configuration. Lastly, some minor changes are expected due to the
activation cleanup of the CPUs.
|
|
The call paths for de-scheduling a thread are halt() and suspend(), from
the thread context. There is no call to deallocateContext() in general,
though some CPUs chose to define it. This patch removes the function
from BaseCPU and the cores which do not require it.
|
|
activate(), suspend(), and halt() used on thread contexts had an optional
delay parameter. However this parameter was often ignored. Also, when used,
the delay was seemily arbitrarily set to 0 or 1 cycle (no other delays were
ever specified). This patch removes the delay parameter and 'Events'
associated with them across all ISAs and cores. Unused activate logic
is also removed.
|
|
This patch changes the CPU and cache configurations used in the ARM SE and FS
regressions to make them more representative, and also get better code
coverage by exercising different replacement policies and use an L2
prefetcher.
|
|
This patch changes the name of the Bus classes to XBar to better
reflect the actual timing behaviour. The actual instances in the
config scripts are not renamed, and remain as e.g. iobus or membus.
As part of this renaming, the code has also been clean up slightly,
making use of range-based for loops and tidying up some comments. The
only changes outside the bus/crossbar code is due to the delay
variables in the packet.
--HG--
rename : src/mem/Bus.py => src/mem/XBar.py
rename : src/mem/coherent_bus.cc => src/mem/coherent_xbar.cc
rename : src/mem/coherent_bus.hh => src/mem/coherent_xbar.hh
rename : src/mem/noncoherent_bus.cc => src/mem/noncoherent_xbar.cc
rename : src/mem/noncoherent_bus.hh => src/mem/noncoherent_xbar.hh
rename : src/mem/bus.cc => src/mem/xbar.cc
rename : src/mem/bus.hh => src/mem/xbar.hh
|
|
This patch adds a basic regression test for the snoop filter.
--HG--
rename : tests/configs/memtest.py => tests/configs/memtest-filter.py
|
|
Adds a simple access counter for requests and snoops for the snoop filter and
also classifies hits based on whether a single other holder existed or whether
multiple shares held the line.
|
|
|
|
This patch adds a simple counter for both total messages and a histogram for
the fan-out of snoop messages. The fan-out describes to how many ports snoops
had to be sent per incoming request / snoop-from-below. Without any
cleverness, this usually means to either all, or all but the requesting port.
|
|
Adds two public domain algorithms for determining number of set bits and also
whether a value is a power of two, uses the builtin that is available in GCC
and clang for popcount.
|
|
This is a first cut at a simple snoop filter that tracks presence of lines in
the caches "above" it. The snoop filter can be applied at any given cache
hierarchy and will then handle the caches above it appropriately; there is no
need to use this only in the last-level bus.
This design currently has some limitations: missing stats, no notion of clean
evictions (these will not update the underlying snoop filter, because they are
not sent from the evicting cache down), no notion of capacity for the snoop
filter and thus no need for invalidations caused by capacity pressure in the
snoop filter. These are planned to be added on top with future change sets.
|
|
There are cases where users might by accident / intention specify less voltage
operating points thatn frequency points. We consider one of these cases
special: giving only a single voltage to a voltage domain effectively renders
it as a static domain. This patch adds additional logic in the auxiliary parts
of the functionality to handle these cases properly (simple driver asking for
N>1 operating levels, we should return the same voltage for all of them) and
adds error checking code in the voltage domain.
|
|
Tie in the newly created energy controller components in the default
configurations.
|
|
This patch provides an Energy Controller device that provides software
(driver) access to a DVFS handler. The device is currently residing in
the dev/arm tree, but there is nothing inherently ARM specific in the
behaviour. It is currently only tested and supported for ARM Linux,
hence the location.
|
|
These additions allow easier interoperability with and querying from an
additional controller which will be in a separate patch. Also adding warnings
for changing the enabled state of the handler across checkpoint / resume and
deviating from the state in the configuration.
Contributed-by: Akash Bagdia <akash.bagdia@arm.com>
|
|
Added the following parameter to the DRAMCtrl class:
- bank_groups_per_rank
This defaults to 1. For the DDR4 case, the default is overridden to indicate
bank group architecture, with multiple bank groups per rank.
Added the following delays to the DRAMCtrl class:
- tCCD_L : CAS-to-CAS, same bank group delay
- tRRD_L : RAS-to-RAS, same bank group delay
These parameters are only applied when bank group timing is enabled. Bank
group timing is currently enabled only for DDR4 memories.
For all other memories, these delays will default to '0 ns'
In the DRAM controller model, applied the bank group timing to the per bank
parameters actAllowedAt and colAllowedAt.
The actAllowedAt will be updated based on bank group when an ACT is issued.
The colAllowedAt will be updated based on bank group when a RD/WR burst is
issued.
At the moment no modifications are made to the scheduling.
|
|
Add the following delay to the DRAM controller:
- tCS : Different rank bus turnaround delay
This will be applied for
1) read-to-read,
2) write-to-write,
3) write-to-read, and
4) read-to-write
command sequences, where the new command accesses a different rank
than the previous burst.
The delay defaults to 2*tCK for each defined memory class. Note that
this does not correspond to one particular timing constraint, but is a
way of modelling all the associated constraints.
The DRAM controller has some minor changes to prioritize commands to
the same rank. This prioritization will only occur when the command
stream is not switching from a read to write or vice versa (in the
case of switching we have a gap in any case).
To prioritize commands to the same rank, the model will determine if there are
any commands queued (same type) to the same rank as the previous command.
This check will ensure that the 'same rank' command will be able to execute
without adding bubbles to the command flow, e.g. any ACT delay requirements
can be done under the hoods, allowing the burst to issue seamlessly.
|
|
Add new DRAM_ROTATE mode to traffic generator.
This mode will generate DRAM traffic that rotates across
banks per rank, command types, and ranks per channel
The looping order is illustrated below:
for (ranks per channel)
for (command types)
for (banks per rank)
// Generate DRAM Command Series
This patch also adds the read percentage as an input argument to the
DRAM sweep script. If the simulated read percentage is 0 or 100, the
middle for loop does not generate additional commands. This loop is
used only when the read percentage is set to 50, in which case the
middle loop will toggle between read and write commands.
Modified sweep.py script, which generates DRAM traffic.
Added input arguments and support for new DRAM_ROTATE mode.
The script now has input arguments for:
1) Read percentage
2) Number of ranks
3) Address mapping
4) Traffic generator mode (DRAM or DRAM_ROTATE)
The default values are:
100% reads, 1 rank, RoRaBaCoCh address mapping, and DRAM traffic gen mode
For the DRAM traffic mode, added multi-rank support.
|
|
This patch adds support for 9p filesystem proxying over VirtIO. It can
currently operate by connecting to a 9p server over a socket
(VirtIO9PSocket) or by starting the diod 9p server and connecting over
pipe (VirtIO9PDiod).
*WARNING*: Checkpoints are currently not supported for systems with 9p
proxies!
|
|
|
