5e767970d8
Before, for historical reasons, the PCI host device was the default responder on the IO bus, meaning that when there was any type of transaction which didn't have a device to go to, it would end up looking like a PCI config transaction. It's very unlikely that this is what it actually was, and what would happen would be arbitrary and probably not helpful. Also, there was no device in place to respond to accesses in x86's IO port address space. On a real system, these accesses just return junk and are otherwise legal. On systems where there would be physical bus wires they would probably return whatever the last data on the bus was. This would have been helpful when the platform was first being set up because it would make it obvious when the OS tried to access a device that wasn't implemented, but there were a few cases where it would purposefully fiddle with ports with nothing on them. These had one off backing devices in the config which would handle the accesses harmlessly, but if the OS changed and tried to access other ports, the configs would need to be updated. Now, the PCI host is just another device on the bus. It claims all of the PCI config space addresses, so any config access, even ones which don't go with a device, will go to it, and it can respond with all 1s like it's supposed to. In it's place, the default responder is now a bus. On that bus is a device which responds to the entire IO port address range with 0s. The default on *that* bus is a device which will mark any accesses as bad. With this setup, accesses which don't go to a device, including a device on the IO port address space, will go to the IO bus's default port. There, if the access was an IO access, it will go to the device which replies successfully with all 0s. If not, it's marked as an error. The device which backs the entire IO address space doesn't conflict with the actual IO devices, since the access will only go towards it if it's otherwise unclaimed, and the devices on the default bus don't participate in routing on the higher level IO bus. Change-Id: Ie02ad7165dfad3ee6f4a762e2f01f7f1b8225168 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35515 Reviewed-by: Matthew Poremba <matthew.poremba@amd.com> Maintainer: Gabe Black <gabeblack@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
This is the gem5 simulator. The main website can be found at http://www.gem5.org A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction. To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of the aforementioned tools. Once you have all dependencies resolved, type 'scons build/<ARCH>/gem5.opt' where ARCH is one of ARM, NULL, MIPS, POWER, SPARC, or X86. This will build an optimized version of the gem5 binary (gem5.opt) for the the specified architecture. See http://www.gem5.org/documentation/general_docs/building for more details and options. The basic source release includes these subdirectories: - configs: example simulation configuration scripts - ext: less-common external packages needed to build gem5 - src: source code of the gem5 simulator - system: source for some optional system software for simulated systems - tests: regression tests - util: useful utility programs and files To run full-system simulations, you will need compiled system firmware (console and PALcode for Alpha), kernel binaries and one or more disk images. If you have questions, please send mail to gem5-users@gem5.org Enjoy using gem5 and please share your modifications and extensions.